[commit?] Patch allows separate input and output audio device (on Mac)
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Re: Re: [commit?] Patch allows separate input and output audio device (on Mac)
by Josh Parmenter
::
Rate this Message:
Hi Dan,
Maybe I can help figure out how to solve this... that seems like a big difference to have in SVN, and now that I think about it, effectively breaks standalone apps. I'll see if I can find a solution later today (though it sounds tricky!). Is there perhaps way check if the Server is internal, and to NOT create the Aggregate in the time being? If so, I think that is a better interim solution then failed starts... Just my 2c, Josh On Jul 10, 2008, at 5:52 AM, Dan Stowell wrote: > That's correct. > > Dan > > > 2008/7/10 Josh Parmenter <josh@...>: >> So for the time being, to use the internal server, we have to make >> sure an >> already aggregated device is chosen in the options? Is that >> correct, or is >> there another work around? >> >> Josh >> >> On Jul 10, 2008, at 4:10 AM, Dan Stowell wrote: >> >>> This is now committed (svn rev 7670). Grateful for reports of >>> successes, failures etc. >>> >>> I've tweaked the patch slightly but not significantly. Had a >>> conversation[1] over on the "coreaudio-api" list with an Apple >>> person, >>> about the problem with internal server. I now suspect that a mutex >>> lockup occurs and that's what's preventing the internal server from >>> starting when using the aggregate device. The solution would be to >>> move the launch into a new thread rather than booting synchronously. >>> For now that's "future work". >>> >>> Dan >>> >>> [1] >>> http://lists.apple.com/archives/Coreaudio-api/2008/Jul/threads.html >>> >>> >>> 2008/7/6 Dan Stowell <danstowell@...>: >>>> >>>> Apart from this Internal-Server isue the patch seems fine, I've >>>> been >>>> running it on both PPC and Intel this week. >>>> >>>> I'm thinking about committing this patch. It certainly reduces the >>>> "Aggregate Device" issue a long way and should hopefully prevent >>>> one >>>> or two users getting frightened off SC. Comments welcome >>>> >>>> Dan >>>> >>>> >>>> 2008/7/2, Axel Balley <a.balley@...>: >>>>> >>>>> I'm getting this too. For some reason the IOProc callback for the >>>>> AudioDevice is never called, so the condition signal is never >>>>> sent for >>>>> the >>>>> RunThread to do its work. >>>>> >>>>> Axel >>>>> >>>>> Le 2 juil. 08 à 12:49, Dan Stowell a écrit : >>>>> >>>>> >>>>> >>>>>> I've just spotted an issue. On my Intel Mac, the local server >>>>>> works >>>>>> fine with this, but the Internal Server can't seem to boot when >>>>>> the >>>>>> magic automatic aggregate is used. Do others see this behaviour? >>>>>> >>>>>> Not sure exactly what's causing it. It looks like >>>>>> SC_AudioDriver::RunThread() gets trapped waiting for a sync >>>>>> message of >>>>>> some sort. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> 2008/6/30 Dan Stowell <danstowell@...>: >>>>>> >>>>>>> I've just applied this patch on my Intel Mac at work, and it >>>>>>> works >>>>> >>>>> smoothly. >>>>>>> >>>>>>> I'd like to suggest that we commit this patch. It will be a >>>>>>> great >>>>>>> advantage for beginners at SC, given that Intel Macs are so >>>>>>> common >>>>>>> now, not to have to fiddle with strangely-named settings in >>>>>>> their >>>>>>> Audio Midi Setup. >>>>>>> >>>>>>> Comments and further test reports welcome. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> 2008/6/29 Axel Balley <a.balley@...>: >>>>>>> >>>>>>>> A few words about the cleanup in the last patch : the CoreAudio >>>>>>>> driver >>>>> >>>>> class >>>>>>>> >>>>>>>> now holds only one mDevice member as well as one streamDesc. >>>>>>>> All >>>>>>>> calls >>>>> >>>>> to >>>>>>>> >>>>>>>> UseSeparateIO() are now unnecessary since there's one device >>>>>>>> only. >>>>>>>> Axel >>>>>>>> >>>>>>>> Axel Balley writes: >>>>>>>> >>>>>>>>> >>>>>>>>> Since the CoreAudio driver now never runs in a state where the >>>>> >>>>> inputDevice >>>>>>>>> >>>>>>>>> is different from the outputDevice (the aggregate takes over >>>>>>>>> in that >>>>> >>>>> case), >>>>>>>>> >>>>>>>>> the code can be cleaned up quite a bit. Also, the server >>>>>>>>> will now >>>>> >>>>> print out >>>>>>>>> >>>>>>>>> the names of the subdevices of the aggregate before the >>>>>>>>> input and >>>>> >>>>> output >>>>>>>>> >>>>>>>>> streams are listed. >>>>>>>>> Attached is the latest patch that combines this and previous >>>>> >>>>> changes. >>>>>>>>> >>>>>>>>> Feedback is welcome ! >>>>>>>>> Cheers, >>>>>>>>> Axel >>>>>>>>> Dan Stowell writes: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2008/6/28 Axel Balley <a.balley@...>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Dan Stowell writes: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A couple of minor issues, non-show-stopping: >>>>>>>>>>>> (1) The aggregate device contains the inputs and outputs of >>>>> >>>>> both >>>>>>>>>>>> >>>>>>>>>>>> devices, rather than the input of one device, and the >>>>>>>>>>>> output >>>>> >>>>> of the >>>>>>>>>>>> >>>>>>>>>>>> other. This is actually pretty cool on my PPC Mac because I >>>>> >>>>> get lots >>>>>>>>>>>> >>>>>>>>>>>> of ins and lots of outs when adding the builtin to my >>>>>>>>>>>> firewire >>>>> >>>>> box. On >>>>>>>>>>>> >>>>>>>>>>>> Intel Mac with no explicit choices of device, I'm assuming >>>>> >>>>> that you >>>>>>>>>>>> >>>>>>>>>>>> end up with the expected behaviour, i.e. built-in-input and >>>>> >>>>> the >>>>>>>>>>>> >>>>>>>>>>>> built-in output - are you on Intel, Axel, and does that >>>>>>>>>>>> happen >>>>> >>>>> for >>>>>>>>>>>> >>>>>>>>>>>> you? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As far as I know about aggregate devices, you can't create >>>>>>>>>>> an >>>>> >>>>> aggregate >>>>>>>>>>> >>>>>>>>>>> that >>>>>>>>>>> only holds a subset of the inputs/outputs of the >>>>>>>>>>> subdevices in >>>>> >>>>> it. You >>>>>>>>>>> >>>>>>>>>>> get >>>>>>>>>>> all of them in one device. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes, that's right. Given what you say (below) about default >>>>>>>>>> Intel >>>>>>>>>> behaviour I think this is fine, although we might want to >>>>>>>>>> think >>>>> >>>>> about >>>>>>>>>> >>>>>>>>>> this further. Hopefully others will try it out using the >>>>>>>>>> attached >>>>>>>>>> patch :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I'm on Intel by the way, and the patch behaves as expected >>>>>>>>>>> with >>>>> >>>>> the >>>>>>>>>>> >>>>>>>>>>> built-in >>>>>>>>>>> input/output devices (I end up with one device that has >>>>>>>>>>> one In >>>>> >>>>> and one >>>>>>>>>>> >>>>>>>>>>> Out). >>>>>>>>>>> If my default OS devices are Built-In Mic and Firepod, I >>>>>>>>>>> get an >>>>>>>>>>> aggregate >>>>>>>>>>> that has : >>>>>>>>>>> Ins : 10 Firepod Ins + 1 Built-in Mic >>>>>>>>>>> Outs : 10 Firepod Outs >>>>>>>>>>> This can be confusing though, and it's why I'd still like to >>>>> >>>>> investigate >>>>>>>>>>> >>>>>>>>>>> how >>>>>>>>>>> hard it would be to deal with two devices without going the >>>>> >>>>> aggregate >>>>>>>>>>> >>>>>>>>>>> way. >>>>>>>>>>> I'm guessing it could bring up plenty of problems regarding >>>>> >>>>> sample rate >>>>>>>>>>> >>>>>>>>>>> mismatch or syncronisation. Still, it seems like the Core >>>>>>>>>>> Audio >>>>> >>>>> driver >>>>>>>>>>> >>>>>>>>>>> for >>>>>>>>>>> SC was designed with multiple devices in mind, so maybe >>>>>>>>>>> it'd be >>>>> >>>>> good to >>>>>>>>>>> >>>>>>>>>>> hear >>>>>>>>>>> from jmc himself about this matter. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Understood. Yes, the code re separate devices is tantalising. >>>>> >>>>> However, >>>>>>>>>> >>>>>>>>>> the Aggregate Device mechanism does some nice things for us >>>>>>>>>> that >>>>> >>>>> might >>>>>>>>>> >>>>>>>>>> need to be re-implemented in SC code if we avoid ADs >>>>>>>>>> (bleh). And >>>>> >>>>> the >>>>>>>>>> >>>>>>>>>> vestigial code might be vestigial for a reason...? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> (2) The "SCAggregate" device appears in the list if I >>>>>>>>>>>> open up >>>>> >>>>> my >>>>>>>>>>>> >>>>>>>>>>>> "Audio MIDI Setup" panel (while the server is booted, at >>>>> >>>>> least). We >>>>>>>>>>>> >>>>>>>>>>>> should probably make it private, that sound OK? Better than >>>>> >>>>> confusing >>>>>>>>>>>> >>>>>>>>>>>> users with mysterious things appearing. I can't right now >>>>>>>>>>>> spot >>>>> >>>>> the >>>>>>>>>>>> >>>>>>>>>>>> tweak for that, but I was reading it yesterday... >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That seems better to me too. I'll give it a look. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OK, I've found it. In the CFDictionary used to request the >>>>>>>>>> AD, you >>>>>>>>>> just add a key "private"=>1. I've added this to the code. >>>>>>>>>> Attached is a patch for what we have so far. So it combines >>>>>>>>>> our >>>>> >>>>> two >>>>>>>>>> >>>>>>>>>> patches, plus (a) setting the AD as private, (b) SC_Jack.cpp >>>>> >>>>> update to >>>>>>>>>> >>>>>>>>>> match, (c) two-devices option only active for Mac. Comments >>>>> >>>>> welcome. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2008/6/26 Axel Balley <a.balley@...>: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> One more time, this time with proper CFRelease of >>>>> >>>>> intermediary >>>>>>>>>>>>> >>>>>>>>>>>>> objects... >>>>>>>>>>>>> >>>>>>>>>>>>> Le 27 juin 08 à 00:47, Axel Balley a écrit : >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> To give credit where it's due, the idea of creating >>>>> >>>>> Aggregate Devices >>>>>>>>>>>>>> >>>>>>>>>>>>>> on >>>>>>>>>>>>>> the fly was from Scott on the users list. Anyway, >>>>>>>>>>>>>> attached >>>>> >>>>> is a patch >>>>>>>>>>>>>> >>>>>>>>>>>>>> with a >>>>>>>>>>>>>> quick hack at it. >>>>>>>>>>>>>> When no hardware device is selected at launch, the server >>>>> >>>>> chooses the >>>>>>>>>>>>>> >>>>>>>>>>>>>> system default input and output. Up until now, there was >>>>> >>>>> no way of >>>>>>>>>>>>>> >>>>>>>>>>>>>> getting >>>>>>>>>>>>>> input to work when those two devices were different. >>>>>>>>>>>>>> With this patch, the server automatically creates an >>>>> >>>>> aggregate device >>>>>>>>>>>>>> >>>>>>>>>>>>>> of >>>>>>>>>>>>>> the input and output when it is necessary (i.e they are >>>>> >>>>> different >>>>>>>>>>>>>> >>>>>>>>>>>>>> devices). >>>>>>>>>>>>>> The aggregate is then selected as the new input/output. >>>>>>>>>>>>>> It >>>>> >>>>> is >>>>>>>>>>>>>> >>>>>>>>>>>>>> destroyed >>>>>>>>>>>>>> on >>>>>>>>>>>>>> release of the server. >>>>>>>>>>>>>> Note that if the server crashes, you'll have to cleanup >>>>> >>>>> the Aggregate >>>>>>>>>>>>>> >>>>>>>>>>>>>> Device yourself in the Audio MIDI Setup utility. Also, >>>>>>>>>>>>>> the >>>>> >>>>> auto >>>>>>>>>>>>>> >>>>>>>>>>>>>> aggregation >>>>>>>>>>>>>> is not done when the user specifies a device at launch >>>>> >>>>> (this doesn't >>>>>>>>>>>>>> >>>>>>>>>>>>>> make >>>>>>>>>>>>>> use of Dan's patch yet). >>>>>>>>>>>>>> This works on my Leopard, let me know how it does on your >>>>> >>>>> system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> <AutoAggregate.patch.txt> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Axel >>>>>>>>>>>>>> Le 26 juin 08 à 19:33, Dan Stowell a écrit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2008/6/26 nescivi <nescivi@...>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thursday 26 June 2008 06:21:56 Dan Stowell wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Axel's right, there is some vestigial code which >>>>> >>>>> seems to prepare >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> separate input/output devices. We should get this >>>>> >>>>> working. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It's probably quite true that the need to piss >>>>> >>>>> around with >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Aggregate >>>>>>>>>>>>>>>>> Devices could put new users off very easily, so I'd >>>>> >>>>> argue this is >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>> pretty important issue. We should make the >>>>> >>>>> first-time experience >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>> smooth and pleasant as possible. >>>>>>>>>>>>>>>>> Attached is a patch which gets us close-ish to >>>>> >>>>> supporting this. It >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> shouldn't break anything - the default behaviour >>>>> >>>>> remains the same, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> you can use s.options.device to set/get the audio >>>>> >>>>> device for both >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I & >>>>>>>>>>>>>>>>> O. However, you can also use s.options.deviceIn and >>>>>>>>>>>>>>>>> s.options.deviceOut to set them independently. >>>>>>>>>>>>>>>>> It seems to work, to the extent that scsynth will >>>>> >>>>> boot and confirm >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> that it's connected to X for input and Y for output. >>>>> >>>>> However, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> running >>>>>>>>>>>>>>>>> code like {AudioIn.ar(1)}.play doesn't work - output >>>>> >>>>> works fine >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>> scsynth doesn't seem to be taking the audio input >>>>> >>>>> data, not on my >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> system at least. (It all works fine if >>>>> >>>>> input==output) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (I'm testing this on a PPC Mac, switching between >>>>> >>>>> built-in audio >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> an Edirol FA-66 box.) >>>>>>>>>>>>>>>>> Can anyone report success/failure using this patch >>>>> >>>>> (e.g. on an >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Intel >>>>>>>>>>>>>>>>> Mac)? >>>>>>>>>>>>>>>>> And can anyone help get it fully working? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This patch would require changes also in SC_Jack.cpp >>>>> >>>>> and probably >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>> in for the windows backend. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for pointing that out. They're simple >>>>> >>>>> find-and-replace >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>> so that's OK. The Windows I *think* is OK since I think >>>>> >>>>> it uses the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Portaudio code which is in SC_CoreAudio.cpp (!). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Having different audio backends on Linux, doesn't make >>>>> >>>>> much sense, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>> would fail anyways, if they are not tied to the same >>>>> >>>>> sync. Besides, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> JACK >>>>>>>>>>>>>>>> gives you all the flexibility you need. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. I was thinking of maybe adding a preprocessor >>>>> >>>>> switch, so that >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> commandline arg parser doesn't look for a second device >>>>> >>>>> name, on >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> non-Mac platforms...? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am guessing that also on Mac you'd need to have the >>>>> >>>>> two cards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> sync'ed >>>>>>>>>>>>>>>> somehow, if it is not the built-in audio (assuming the >>>>> >>>>> built-in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> audio >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>> actually the same device, just with different >>>>> >>>>> interfaces in the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OS). >>>>>>>>>>>>>>>> Can you normally make working aggregate devices >>>>> >>>>> between a built-in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> soundcard >>>>>>>>>>>>>>>> and an external one, without having them share a >>>>> >>>>> clock? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In an aggregate device you nominate where the clock >>>>> >>>>> comes from. You >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> can also opt for resampling to be done, which I guess >>>>> >>>>> might handle >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> mismatched sample-rates. So, rather than handling this >>>>> >>>>> kind of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> business in scsynth's code, maybe instead we should >>>>> >>>>> create an >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> on-the-fly aggregate device (as suggested by Axel) so as >>>>> >>>>> to benefit >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> from their tricks. >>>>>>>>>>>>>>> Dan >>>>>>>>>>>>>>> >>>>> _______________________________________________ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> sc-dev mailing list >>>>>>>>>>>>>>> info (subscribe and unsubscribe): >>>>>>>>>>>>>>> >>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> archive: >>>>> >>>>> http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> search: >>>>> >>>>> http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> http://www.mcld.co.uk >>>>>>>>>>>> >>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> sc-dev mailing list >>>>>>>>>>>> info (subscribe and unsubscribe): >>>>>>>>>>>> >>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>>>>>> >>>>>>>>>>>> archive: >>>>> >>>>> http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>>>>>>>> >>>>>>>>>>>> search: >>>>> >>>>> http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sc-dev mailing list >>>>>>>>>>> >>>>>>>>>>> info (subscribe and unsubscribe): >>>>>>>>>>> >>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>>>>> >>>>>>>>>>> archive: >>>>> >>>>> http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>>>>>>> >>>>>>>>>>> search: >>>>> >>>>> http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> http://www.mcld.co.uk >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sc-dev mailing list >>>>>>>> >>>>>>>> >>>>>>>> info (subscribe and unsubscribe): >> >> ... >> >> [Pósturinn hefur verið styttur] > > > > -- > http://www.mcld.co.uk > > _______________________________________________ > sc-dev mailing list > > info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ ****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/ “Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono */ _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: Re: [commit?] Patch allows separate input and output audio device (on Mac)
by Dan Stowell
::
Rate this Message:
2008/7/10 Josh Parmenter <josh@...>:
> Hi Dan, > > Maybe I can help figure out how to solve this... that seems like a big > difference to have in SVN and now that I think about it, effectively breaks > standalone apps. It is a big difference, but for the common case it's an improvement. Newbie users will be able to boot the local server without getting bogged down in aggregate devices! Still, I'd be grateful for your help in finding a way around the issue. > I'll see if I can find a solution later today (though it > sounds tricky!). Is there perhaps way check if the Server is internal, and > to NOT create the Aggregate in the time being? If so, I think that is a > better interim solution then failed starts... It may be possible - I'd considered this. It doesn't look to me as if there's an explicit flag/function for "are we internal?" but one way to check is my looking at the number of shared controls (world->mNumSharedControls) - this is always zero if not internal, and I think for the internal server it's always 1024. (I don't use shared controls so I may be wrong.) Can anyone confirm this? If so we could use this fairly painlessly as a test. Dan > Just my 2c, > > Josh > > On Jul 10, 2008, at 5:52 AM, Dan Stowell wrote: > >> That's correct. >> >> Dan >> >> >> 2008/7/10 Josh Parmenter <josh@...>: >>> >>> So for the time being, to use the internal server, we have to make sure >>> an >>> already aggregated device is chosen in the options? Is that correct, or >>> is >>> there another work around? >>> >>> Josh >>> >>> On Jul 10, 2008, at 4:10 AM, Dan Stowell wrote: >>> >>>> This is now committed (svn rev 7670). Grateful for reports of >>>> successes, failures etc. >>>> >>>> I've tweaked the patch slightly but not significantly. Had a >>>> conversation[1] over on the "coreaudio-api" list with an Apple person, >>>> about the problem with internal server. I now suspect that a mutex >>>> lockup occurs and that's what's preventing the internal server from >>>> starting when using the aggregate device. The solution would be to >>>> move the launch into a new thread rather than booting synchronously. >>>> For now that's "future work". >>>> >>>> Dan >>>> >>>> [1] >>>> http://lists.apple.com/archives/Coreaudio-api/2008/Jul/threads.html >>>> >>>> >>>> 2008/7/6 Dan Stowell <danstowell@...>: >>>>> >>>>> Apart from this Internal-Server isue the patch seems fine, I've been >>>>> running it on both PPC and Intel this week. >>>>> >>>>> I'm thinking about committing this patch. It certainly reduces the >>>>> "Aggregate Device" issue a long way and should hopefully prevent one >>>>> or two users getting frightened off SC. Comments welcome >>>>> >>>>> Dan >>>>> >>>>> >>>>> 2008/7/2, Axel Balley <a.balley@...>: >>>>>> >>>>>> I'm getting this too. For some reason the IOProc callback for the >>>>>> AudioDevice is never called, so the condition signal is never sent for >>>>>> the >>>>>> RunThread to do its work. >>>>>> >>>>>> Axel >>>>>> >>>>>> Le 2 juil. 08 à 12:49, Dan Stowell a écrit : >>>>>> >>>>>> >>>>>> >>>>>>> I've just spotted an issue. On my Intel Mac, the local server works >>>>>>> fine with this, but the Internal Server can't seem to boot when the >>>>>>> magic automatic aggregate is used. Do others see this behaviour? >>>>>>> >>>>>>> Not sure exactly what's causing it. It looks like >>>>>>> SC_AudioDriver::RunThread() gets trapped waiting for a sync message >>>>>>> of >>>>>>> some sort. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> 2008/6/30 Dan Stowell <danstowell@...>: >>>>>>> >>>>>>>> I've just applied this patch on my Intel Mac at work, and it works >>>>>> >>>>>> smoothly. >>>>>>>> >>>>>>>> I'd like to suggest that we commit this patch. It will be a great >>>>>>>> advantage for beginners at SC, given that Intel Macs are so common >>>>>>>> now, not to have to fiddle with strangely-named settings in their >>>>>>>> Audio Midi Setup. >>>>>>>> >>>>>>>> Comments and further test reports welcome. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> 2008/6/29 Axel Balley <a.balley@...>: >>>>>>>> >>>>>>>>> A few words about the cleanup in the last patch : the CoreAudio >>>>>>>>> driver >>>>>> >>>>>> class >>>>>>>>> >>>>>>>>> now holds only one mDevice member as well as one streamDesc. All >>>>>>>>> calls >>>>>> >>>>>> to >>>>>>>>> >>>>>>>>> UseSeparateIO() are now unnecessary since there's one device only. >>>>>>>>> Axel >>>>>>>>> >>>>>>>>> Axel Balley writes: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Since the CoreAudio driver now never runs in a state where the >>>>>> >>>>>> inputDevice >>>>>>>>>> >>>>>>>>>> is different from the outputDevice (the aggregate takes over in >>>>>>>>>> that >>>>>> >>>>>> case), >>>>>>>>>> >>>>>>>>>> the code can be cleaned up quite a bit. Also, the server will now >>>>>> >>>>>> print out >>>>>>>>>> >>>>>>>>>> the names of the subdevices of the aggregate before the input and >>>>>> >>>>>> output >>>>>>>>>> >>>>>>>>>> streams are listed. >>>>>>>>>> Attached is the latest patch that combines this and previous >>>>>> >>>>>> changes. >>>>>>>>>> >>>>>>>>>> Feedback is welcome ! >>>>>>>>>> Cheers, >>>>>>>>>> Axel >>>>>>>>>> Dan Stowell writes: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2008/6/28 Axel Balley <a.balley@...>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Dan Stowell writes: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> A couple of minor issues, non-show-stopping: >>>>>>>>>>>>> (1) The aggregate device contains the inputs and outputs of >>>>>> >>>>>> both >>>>>>>>>>>>> >>>>>>>>>>>>> devices, rather than the input of one device, and the output >>>>>> >>>>>> of the >>>>>>>>>>>>> >>>>>>>>>>>>> other. This is actually pretty cool on my PPC Mac because I >>>>>> >>>>>> get lots >>>>>>>>>>>>> >>>>>>>>>>>>> of ins and lots of outs when adding the builtin to my firewire >>>>>> >>>>>> box. On >>>>>>>>>>>>> >>>>>>>>>>>>> Intel Mac with no explicit choices of device, I'm assuming >>>>>> >>>>>> that you >>>>>>>>>>>>> >>>>>>>>>>>>> end up with the expected behaviour, i.e. built-in-input and >>>>>> >>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> built-in output - are you on Intel, Axel, and does that happen >>>>>> >>>>>> for >>>>>>>>>>>>> >>>>>>>>>>>>> you? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As far as I know about aggregate devices, you can't create an >>>>>> >>>>>> aggregate >>>>>>>>>>>> >>>>>>>>>>>> that >>>>>>>>>>>> only holds a subset of the inputs/outputs of the subdevices in >>>>>> >>>>>> it. You >>>>>>>>>>>> >>>>>>>>>>>> get >>>>>>>>>>>> all of them in one device. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes, that's right. Given what you say (below) about default Intel >>>>>>>>>>> behaviour I think this is fine, although we might want to think >>>>>> >>>>>> about >>>>>>>>>>> >>>>>>>>>>> this further. Hopefully others will try it out using the attached >>>>>>>>>>> patch :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'm on Intel by the way, and the patch behaves as expected with >>>>>> >>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> built-in >>>>>>>>>>>> input/output devices (I end up with one device that has one In >>>>>> >>>>>> and one >>>>>>>>>>>> >>>>>>>>>>>> Out). >>>>>>>>>>>> If my default OS devices are Built-In Mic and Firepod, I get an >>>>>>>>>>>> aggregate >>>>>>>>>>>> that has : >>>>>>>>>>>> Ins : 10 Firepod Ins + 1 Built-in Mic >>>>>>>>>>>> Outs : 10 Firepod Outs >>>>>>>>>>>> This can be confusing though, and it's why I'd still like to >>>>>> >>>>>> investigate >>>>>>>>>>>> >>>>>>>>>>>> how >>>>>>>>>>>> hard it would be to deal with two devices without going the >>>>>> >>>>>> aggregate >>>>>>>>>>>> >>>>>>>>>>>> way. >>>>>>>>>>>> I'm guessing it could bring up plenty of problems regarding >>>>>> >>>>>> sample rate >>>>>>>>>>>> >>>>>>>>>>>> mismatch or syncronisation. Still, it seems like the Core Audio >>>>>> >>>>>> driver >>>>>>>>>>>> >>>>>>>>>>>> for >>>>>>>>>>>> SC was designed with multiple devices in mind, so maybe it'd be >>>>>> >>>>>> good to >>>>>>>>>>>> >>>>>>>>>>>> hear >>>>>>>>>>>> from jmc himself about this matter. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Understood. Yes, the code re separate devices is tantalising. >>>>>> >>>>>> However, >>>>>>>>>>> >>>>>>>>>>> the Aggregate Device mechanism does some nice things for us that >>>>>> >>>>>> might >>>>>>>>>>> >>>>>>>>>>> need to be re-implemented in SC code if we avoid ADs (bleh). And >>>>>> >>>>>> the >>>>>>>>>>> >>>>>>>>>>> vestigial code might be vestigial for a reason...? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> (2) The "SCAggregate" device appears in the list if I open up >>>>>> >>>>>> my >>>>>>>>>>>>> >>>>>>>>>>>>> "Audio MIDI Setup" panel (while the server is booted, at >>>>>> >>>>>> least). We >>>>>>>>>>>>> >>>>>>>>>>>>> should probably make it private, that sound OK? Better than >>>>>> >>>>>> confusing >>>>>>>>>>>>> >>>>>>>>>>>>> users with mysterious things appearing. I can't right now spot >>>>>> >>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> tweak for that, but I was reading it yesterday... >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That seems better to me too. I'll give it a look. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> OK, I've found it. In the CFDictionary used to request the AD, >>>>>>>>>>> you >>>>>>>>>>> just add a key "private"=>1. I've added this to the code. >>>>>>>>>>> Attached is a patch for what we have so far. So it combines our >>>>>> >>>>>> two >>>>>>>>>>> >>>>>>>>>>> patches, plus (a) setting the AD as private, (b) SC_Jack.cpp >>>>>> >>>>>> update to >>>>>>>>>>> >>>>>>>>>>> match, (c) two-devices option only active for Mac. Comments >>>>>> >>>>>> welcome. >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 2008/6/26 Axel Balley <a.balley@...>: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> One more time, this time with proper CFRelease of >>>>>> >>>>>> intermediary >>>>>>>>>>>>>> >>>>>>>>>>>>>> objects... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le 27 juin 08 à 00:47, Axel Balley a écrit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To give credit where it's due, the idea of creating >>>>>> >>>>>> Aggregate Devices >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> on >>>>>>>>>>>>>>> the fly was from Scott on the users list. Anyway, attached >>>>>> >>>>>> is a patch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with a >>>>>>>>>>>>>>> quick hack at it. >>>>>>>>>>>>>>> When no hardware device is selected at launch, the server >>>>>> >>>>>> chooses the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> system default input and output. Up until now, there was >>>>>> >>>>>> no way of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> getting >>>>>>>>>>>>>>> input to work when those two devices were different. >>>>>>>>>>>>>>> With this patch, the server automatically creates an >>>>>> >>>>>> aggregate device >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> the input and output when it is necessary (i.e they are >>>>>> >>>>>> different >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> devices). >>>>>>>>>>>>>>> The aggregate is then selected as the new input/output. It >>>>>> >>>>>> is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> destroyed >>>>>>>>>>>>>>> on >>>>>>>>>>>>>>> release of the server. >>>>>>>>>>>>>>> Note that if the server crashes, you'll have to cleanup >>>>>> >>>>>> the Aggregate >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Device yourself in the Audio MIDI Setup utility. Also, the >>>>>> >>>>>> auto >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> aggregation >>>>>>>>>>>>>>> is not done when the user specifies a device at launch >>>>>> >>>>>> (this doesn't >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> make >>>>>>>>>>>>>>> use of Dan's patch yet). >>>>>>>>>>>>>>> This works on my Leopard, let me know how it does on your >>>>>> >>>>>> system. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <AutoAggregate.patch.txt> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Axel >>>>>>>>>>>>>>> Le 26 juin 08 à 19:33, Dan Stowell a écrit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2008/6/26 nescivi <nescivi@...>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thursday 26 June 2008 06:21:56 Dan Stowell wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Axel's right, there is some vestigial code which >>>>>> >>>>>> seems to prepare >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> separate input/output devices. We should get this >>>>>> >>>>>> working. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It's probably quite true that the need to piss >>>>>> >>>>>> around with >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Aggregate >>>>>>>>>>>>>>>>>> Devices could put new users off very easily, so I'd >>>>>> >>>>>> argue this is >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>> pretty important issue. We should make the >>>>>> >>>>>> first-time experience >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>> smooth and pleasant as possible. >>>>>>>>>>>>>>>>>> Attached is a patch which gets us close-ish to >>>>>> >>>>>> supporting this. It >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> shouldn't break anything - the default behaviour >>>>>> >>>>>> remains the same, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> you can use s.options.device to set/get the audio >>>>>> >>>>>> device for both >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I & >>>>>>>>>>>>>>>>>> O. However, you can also use s.options.deviceIn and >>>>>>>>>>>>>>>>>> s.options.deviceOut to set them independently. >>>>>>>>>>>>>>>>>> It seems to work, to the extent that scsynth will >>>>>> >>>>>> boot and confirm >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> that it's connected to X for input and Y for output. >>>>>> >>>>>> However, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> running >>>>>>>>>>>>>>>>>> code like {AudioIn.ar(1)}.play doesn't work - output >>>>>> >>>>>> works fine >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>> scsynth doesn't seem to be taking the audio input >>>>>> >>>>>> data, not on my >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> system at least. (It all works fine if >>>>>> >>>>>> input==output) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> (I'm testing this on a PPC Mac, switching between >>>>>> >>>>>> built-in audio >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> an Edirol FA-66 box.) >>>>>>>>>>>>>>>>>> Can anyone report success/failure using this patch >>>>>> >>>>>> (e.g. on an >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Intel >>>>>>>>>>>>>>>>>> Mac)? >>>>>>>>>>>>>>>>>> And can anyone help get it fully working? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This patch would require changes also in SC_Jack.cpp >>>>>> >>>>>> and probably >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>> in for the windows backend. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for pointing that out. They're simple >>>>>> >>>>>> find-and-replace >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>> so that's OK. The Windows I *think* is OK since I think >>>>>> >>>>>> it uses the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Portaudio code which is in SC_CoreAudio.cpp (!). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Having different audio backends on Linux, doesn't make >>>>>> >>>>>> much sense, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>> would fail anyways, if they are not tied to the same >>>>>> >>>>>> sync. Besides, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> JACK >>>>>>>>>>>>>>>>> gives you all the flexibility you need. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes. I was thinking of maybe adding a preprocessor >>>>>> >>>>>> switch, so that >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> commandline arg parser doesn't look for a second device >>>>>> >>>>>> name, on >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> non-Mac platforms...? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am guessing that also on Mac you'd need to have the >>>>>> >>>>>> two cards >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> sync'ed >>>>>>>>>>>>>>>>> somehow, if it is not the built-in audio (assuming the >>>>>> >>>>>> built-in >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> audio >>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>> actually the same device, just with different >>>>>> >>>>>> interfaces in the >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OS). >>>>>>>>>>>>>>>>> Can you normally make working aggregate devices >>>>>> >>>>>> between a built-in >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> soundcard >>>>>>>>>>>>>>>>> and an external one, without having them share a >>>>>> >>>>>> clock? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In an aggregate device you nominate where the clock >>>>>> >>>>>> comes from. You >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> can also opt for resampling to be done, which I guess >>>>>> >>>>>> might handle >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> mismatched sample-rates. So, rather than handling this >>>>>> >>>>>> kind of >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> business in scsynth's code, maybe instead we should >>>>>> >>>>>> create an >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> on-the-fly aggregate device (as suggested by Axel) so as >>>>>> >>>>>> to benefit >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> from their tricks. >>>>>>>>>>>>>>>> Dan >>>>>>>>>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> sc-dev mailing list >>>>>>>>>>>>>>>> info (subscribe and unsubscribe): >>>>>>>>>>>>>>>> >>>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> archive: >>>>>> >>>>>> http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> search: >>>>>> >>>>>> http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> http://www.mcld.co.uk >>>>>>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> sc-dev mailing list >>>>>>>>>>>>> info (subscribe and unsubscribe): >>>>>>>>>>>>> >>>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>>>>>>> >>>>>>>>>>>>> archive: >>>>>> >>>>>> http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>>>>>>>>> >>>>>>>>>>>>> search: >>>>>> >>>>>> http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sc-dev mailing list >>>>>>>>>>>> >>>>>>>>>>>> info (subscribe and unsubscribe): >>>>>>>>>>>> >>>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>>>>>> >>>>>>>>>>>> archive: > > ... > > [Pósturinn hefur verið styttur] -- http://www.mcld.co.uk _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: Re: [commit?] Patch allows separate input and output audio device (on Mac)
by nescivi
::
Rate this Message:
On Thursday 10 July 2008 11:11:06 Dan Stowell wrote:
> 2008/7/10 Josh Parmenter <josh@...>: > > Hi Dan, > > > > Maybe I can help figure out how to solve this... that seems like a big > > difference to have in SVN and now that I think about it, effectively > > breaks standalone apps. > > It is a big difference, but for the common case it's an improvement. > Newbie users will be able to boot the local server without getting > bogged down in aggregate devices! Still, I'd be grateful for your help > in finding a way around the issue. If I understand correctly, it would break any examples where the scope is being used (on Mac)... and the scope can be quite useful in teaching... sincerely, Marije _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: Re: [commit?] Patch allows separate input and output audio device (on Mac)
by James Harkins-2
::
Rate this Message:
On Thu, Jul 10, 2008 at 11:48 AM, nescivi <nescivi@...> wrote:
> If I understand correctly, it would break any examples where the scope is > being used (on Mac)... and the scope can be quite useful in teaching... Correct me if I'm wrong, but you should still be able to boot the internal server provided the input and output devices match -- is that right? That is, the patch kicks in only if input and output are not the same. So this should not destroy .scope altogether IIUC. hjh -- James Harkins /// dewdrop world jamshark70@... http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: Re: [commit?] Patch allows separate input and output audio device (on Mac)
by nescivi
::
Rate this Message:
On Thursday 10 July 2008 11:54:52 James Harkins wrote:
> On Thu, Jul 10, 2008 at 11:48 AM, nescivi <nescivi@...> wrote: > > If I understand correctly, it would break any examples where the scope is > > being used (on Mac)... and the scope can be quite useful in teaching... > > Correct me if I'm wrong, but you should still be able to boot the > internal server provided the input and output devices match -- is that > right? That is, the patch kicks in only if input and output are not > the same. > > So this should not destroy .scope altogether IIUC. but adds inconsistency... and then you still have to explain the students about creating the aggregate device... sincerely, Marije _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
|
