Patch for separate input and output - without agregate devices

[Axel BALLEY-2]

This might be a bit late to change directions, but I think I got  
support for separate input and output to work without dealing with  
agregate devices at all. The IOProc gets called separately for the  
input and the ouput device when they are different. As usual, it's  
called just once when they're the same. The node calculations are ran  
only during the output device callback, which uses the input data  
received during the last input device callback.
This works on my intel mac on both internal and local server.

This patch works on rev 7669, that is before the previous patch using  
aggregate devices was commited. Should we choose to go this direction,  
Dan's changes to the inDevice/outDevice server options will have to be  
put back in, but that should be fairly quick to do.

Advantages of this route :
- less code needed
- avoid aggregate devices API bugs
- a more predictable set of inputs and outputs when the user selects  
an input device that also has output streams, and vice versa (the  
aggregate devices would just mix everything, which is not necessary  
what the user wants)

I haven't run into syncronisation issues between input and output,  
please let me know how this works on your end !

Cheers,

Axel

[Josh Parmenter]

I think this makes sense as well...

anyone else?

Josh

On Jul 10, 2008, at 3:04 PM, Axel Balley wrote:

> This might be a bit late to change directions, but I think I got  
> support for separate input and output to work without dealing with  
> agregate devices at all. The IOProc gets called separately for the  
> input and the ouput device when they are different. As usual, it's  
> called just once when they're the same. The node calculations are  
> ran only during the output device callback, which uses the input  
> data received during the last input device callback.
> This works on my intel mac on both internal and local server.
>
> This patch works on rev 7669, that is before the previous patch  
> using aggregate devices was commited. Should we choose to go this  
> direction, Dan's changes to the inDevice/outDevice server options  
> will have to be put back in, but that should be fairly quick to do.
>
> Advantages of this route :
> - less code needed
> - avoid aggregate devices API bugs
> - a more predictable set of inputs and outputs when the user selects  
> an input device that also has output streams, and vice versa (the  
> aggregate devices would just mix everything, which is not necessary  
> what the user wants)
>
> I haven't run into syncronisation issues between input and output,  
> please let me know how this works on your end !
>
> Cheers,
>
> Axel
>
> <SeparateIO_NoAgregateRev7669.patch>

******************************************
/* 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/

[Josh Parmenter]

I just tested this a bit more on my intel MacBook... works great for  
both servers, and standalones work as well!

Best,

Josh

On Jul 10, 2008, at 3:04 PM, Axel Balley wrote:

> This might be a bit late to change directions, but I think I got  
> support for separate input and output to work without dealing with  
> agregate devices at all. The IOProc gets called separately for the  
> input and the ouput device when they are different. As usual, it's  
> called just once when they're the same. The node calculations are  
> ran only during the output device callback, which uses the input  
> data received during the last input device callback.
> This works on my intel mac on both internal and local server.
>
> This patch works on rev 7669, that is before the previous patch  
> using aggregate devices was commited. Should we choose to go this  
> direction, Dan's changes to the inDevice/outDevice server options  
> will have to be put back in, but that should be fairly quick to do.
>
> Advantages of this route :
> - less code needed
> - avoid aggregate devices API bugs
> - a more predictable set of inputs and outputs when the user selects  
> an input device that also has output streams, and vice versa (the  
> aggregate devices would just mix everything, which is not necessary  
> what the user wants)
>
> I haven't run into syncronisation issues between input and output,  
> please let me know how this works on your end !
>
> Cheers,
>
> Axel
>
> <SeparateIO_NoAgregateRev7669.patch>

******************************************
/* 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/

[Dan Stowell]

Hi -

This doesn't seem to work for me I'm afraid: the server claims to boot
happily with separate devices, but audio input doesn't actually
happen. I'm on PPC, and testing by using Audio Midi Setup to set input
as firewire box and output as builtin, or vice versa. No difference
between local and internal server in this case.

Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play actually
plays sound through for them, with the patch?

Dan


2008/7/10 Axel Balley <a.balley@...>:

> This might be a bit late to change directions, but I think I got support for
> separate input and output to work without dealing with agregate devices at
> all. The IOProc gets called separately for the input and the ouput device
> when they are different. As usual, it's called just once when they're the
> same. The node calculations are ran only during the output device callback,
> which uses the input data received during the last input device callback.
> This works on my intel mac on both internal and local server.
>
> This patch works on rev 7669, that is before the previous patch using
> aggregate devices was commited. Should we choose to go this direction, Dan's
> changes to the inDevice/outDevice server options will have to be put back
> in, but that should be fairly quick to do.
>
> Advantages of this route :
> - less code needed
> - avoid aggregate devices API bugs
> - a more predictable set of inputs and outputs when the user selects an
> input device that also has output streams, and vice versa (the aggregate
> devices would just mix everything, which is not necessary what the user
> wants)
>
> I haven't run into syncronisation issues between input and output, please
> let me know how this works on your end !
>
> Cheers,
>
> Axel
>
>
>
>
>

--
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/

[Josh Parmenter]

this works for me on intel Mac:

s.boot

{Out.ar(1, AudioIn.ar(1))}.play

and the boot messages:

Number of Devices: 4
    0 : "Built-in Microphone"
    1 : "Built-in Input"
    2 : "Built-in Output"
    3 : "Built-in Audio"

"Built-in Microphone" Input Device
    Streams: 1
       0  channels 2

"Built-in Output" Output Device
    Streams: 1
       0  channels 2

mSafetyOffset 280
mNumberBuffers 1
   mDataByteSize 0 4096
<-SC_CoreAudioDriver::Setup world 0023D800
SC_AudioDriver: numSamples=512, sampleRate=44100.000000
->SC_CoreAudioDriver::DriverStart
start   UseSeparateIO?: 1
<-SC_CoreAudioDriver::DriverStart
SuperCollider 3 server ready..
PublishPortToRendezvous 0 5855
notification is on

I can try tomorrow with a FW interface.

Josh

On Jul 11, 2008, at 1:23 AM, Dan Stowell wrote:

> Hi -
>
> This doesn't seem to work for me I'm afraid: the server claims to boot
> happily with separate devices, but audio input doesn't actually
> happen. I'm on PPC, and testing by using Audio Midi Setup to set input
> as firewire box and output as builtin, or vice versa. No difference
> between local and internal server in this case.
>
> Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play actually
> plays sound through for them, with the patch?
>
> Dan
>
>
> 2008/7/10 Axel Balley <a.balley@...>:
>> This might be a bit late to change directions, but I think I got  
>> support for
>> separate input and output to work without dealing with agregate  
>> devices at
>> all. The IOProc gets called separately for the input and the ouput  
>> device
>> when they are different. As usual, it's called just once when  
>> they're the
>> same. The node calculations are ran only during the output device  
>> callback,
>> which uses the input data received during the last input device  
>> callback.
>> This works on my intel mac on both internal and local server.
>>
>> This patch works on rev 7669, that is before the previous patch using
>> aggregate devices was commited. Should we choose to go this  
>> direction, Dan's
>> changes to the inDevice/outDevice server options will have to be  
>> put back
>> in, but that should be fairly quick to do.
>>
>> Advantages of this route :
>> - less code needed
>> - avoid aggregate devices API bugs
>> - a more predictable set of inputs and outputs when the user  
>> selects an
>> input device that also has output streams, and vice versa (the  
>> aggregate
>> devices would just mix everything, which is not necessary what the  
>> user
>> wants)
>>
>> I haven't run into syncronisation issues between input and output,  
>> please
>> let me know how this works on your end !
>>
>> Cheers,
>>
>> Axel
>>
>>
>>
>>
>>
>
>
>
> --
> 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/

[Josh Parmenter]

by the way, I reverted to 7669, applied the patch, and rebuilt

Josh

On Jul 11, 2008, at 1:23 AM, Dan Stowell wrote:

> Hi -
>
> This doesn't seem to work for me I'm afraid: the server claims to boot
> happily with separate devices, but audio input doesn't actually
> happen. I'm on PPC, and testing by using Audio Midi Setup to set input
> as firewire box and output as builtin, or vice versa. No difference
> between local and internal server in this case.
>
> Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play actually
> plays sound through for them, with the patch?
>
> Dan
>
>
> 2008/7/10 Axel Balley <a.balley@...>:
>> This might be a bit late to change directions, but I think I got  
>> support for
>> separate input and output to work without dealing with agregate  
>> devices at
>> all. The IOProc gets called separately for the input and the ouput  
>> device
>> when they are different. As usual, it's called just once when  
>> they're the
>> same. The node calculations are ran only during the output device  
>> callback,
>> which uses the input data received during the last input device  
>> callback.
>> This works on my intel mac on both internal and local server.
>>
>> This patch works on rev 7669, that is before the previous patch using
>> aggregate devices was commited. Should we choose to go this  
>> direction, Dan's
>> changes to the inDevice/outDevice server options will have to be  
>> put back
>> in, but that should be fairly quick to do.
>>
>> Advantages of this route :
>> - less code needed
>> - avoid aggregate devices API bugs
>> - a more predictable set of inputs and outputs when the user  
>> selects an
>> input device that also has output streams, and vice versa (the  
>> aggregate
>> devices would just mix everything, which is not necessary what the  
>> user
>> wants)
>>
>> I haven't run into syncronisation issues between input and output,  
>> please
>> let me know how this works on your end !
>>
>> Cheers,
>>
>> Axel
>>
>>
>>
>>
>>
>
>
>
> --
> 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/

[Josh Parmenter]

Dan - were you able to get this working?

josh

On Jul 11, 2008, at 1:23 AM, Dan Stowell wrote:

> Hi -
>
> This doesn't seem to work for me I'm afraid: the server claims to boot
> happily with separate devices, but audio input doesn't actually
> happen. I'm on PPC, and testing by using Audio Midi Setup to set input
> as firewire box and output as builtin, or vice versa. No difference
> between local and internal server in this case.
>
> Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play actually
> plays sound through for them, with the patch?
>
> Dan
>
>
> 2008/7/10 Axel Balley <a.balley@...>:
>> This might be a bit late to change directions, but I think I got  
>> support for
>> separate input and output to work without dealing with agregate  
>> devices at
>> all. The IOProc gets called separately for the input and the ouput  
>> device
>> when they are different. As usual, it's called just once when  
>> they're the
>> same. The node calculations are ran only during the output device  
>> callback,
>> which uses the input data received during the last input device  
>> callback.
>> This works on my intel mac on both internal and local server.
>>
>> This patch works on rev 7669, that is before the previous patch using
>> aggregate devices was commited. Should we choose to go this  
>> direction, Dan's
>> changes to the inDevice/outDevice server options will have to be  
>> put back
>> in, but that should be fairly quick to do.
>>
>> Advantages of this route :
>> - less code needed
>> - avoid aggregate devices API bugs
>> - a more predictable set of inputs and outputs when the user  
>> selects an
>> input device that also has output streams, and vice versa (the  
>> aggregate
>> devices would just mix everything, which is not necessary what the  
>> user
>> wants)
>>
>> I haven't run into syncronisation issues between input and output,  
>> please
>> let me know how this works on your end !
>>
>> Cheers,
>>
>> Axel
>>
>>
>>
>>
>>
>
>
>
> --
> 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/

[Dan Stowell]

No, I haven't, although I haven't looked in detail. Did anyone else
try the patch on PPC, and/or with a firewire unit? Reports would be
*very* helpful, in order to pin down what causes the issue.

After setting my firewire box as input and my builtin as output, I
started SC then ran:

  s.boot;
  {AudioIn.ar}.play

and no sound, although there should be. (I do get sound if using
either device exclusively.)

It's definitely input that's missing rather than output, because
SinOsc and friends can make sound, while something like this produces
non-stop zeroes no matter what I do:

  {Amplitude.kr(AudioIn.ar((1..8))).poll}.play

Here's what the boot messages look like:

Number of Devices: 2
   0 : "Built-in Audio"
   1 : "EDIROL FA-66 (3802)"

"EDIROL FA-66 (3802)" Input Device
   Streams: 6
      0  channels 1
      1  channels 1
      2  channels 1
      3  channels 1
      4  channels 1
      5  channels 1

"Built-in Audio" Output Device
   Streams: 1
      0  channels 2

mSafetyOffset 57
mNumberBuffers 6
  mDataByteSize 0 2048
  mDataByteSize 1 2048
  mDataByteSize 2 2048
  mDataByteSize 3 2048
  mDataByteSize 4 2048
  mDataByteSize 5 2048
<-SC_CoreAudioDriver::Setup world 00626880
SC_AudioDriver: numSamples=512, sampleRate=44100.000000
->SC_CoreAudioDriver::DriverStart
start   UseSeparateIO?: 1
<-SC_CoreAudioDriver::DriverStart
SuperCollider 3 server ready..
notification is on




2008/7/11 Josh Parmenter <josh@...>:

> Dan - were you able to get this working?
>
> josh
>
> On Jul 11, 2008, at 1:23 AM, Dan Stowell wrote:
>
>> Hi -
>>
>> This doesn't seem to work for me I'm afraid: the server claims to boot
>> happily with separate devices, but audio input doesn't actually
>> happen. I'm on PPC, and testing by using Audio Midi Setup to set input
>> as firewire box and output as builtin, or vice versa. No difference
>> between local and internal server in this case.
>>
>> Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play actually
>> plays sound through for them, with the patch?
>>
>> Dan
>>
>>
>> 2008/7/10 Axel Balley <a.balley@...>:
>>>
>>> This might be a bit late to change directions, but I think I got support
>>> for
>>> separate input and output to work without dealing with agregate devices
>>> at
>>> all. The IOProc gets called separately for the input and the ouput device
>>> when they are different. As usual, it's called just once when they're the
>>> same. The node calculations are ran only during the output device
>>> callback,
>>> which uses the input data received during the last input device callback.
>>> This works on my intel mac on both internal and local server.
>>>
>>> This patch works on rev 7669, that is before the previous patch using
>>> aggregate devices was commited. Should we choose to go this direction,
>>> Dan's
>>> changes to the inDevice/outDevice server options will have to be put back
>>> in, but that should be fairly quick to do.
>>>
>>> Advantages of this route :
>>> - less code needed
>>> - avoid aggregate devices API bugs
>>> - a more predictable set of inputs and outputs when the user selects an
>>> input device that also has output streams, and vice versa (the aggregate
>>> devices would just mix everything, which is not necessary what the user
>>> wants)
>>>
>>> I haven't run into syncronisation issues between input and output, please
>>> let me know how this works on your end !
>>>
>>> Cheers,
>>>
>>> Axel
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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/
>

--
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/

[Josh Parmenter]

Like I mentioned... did you back up the revision before you built?

I'll test with a firewire device in about 15 minutes.

josh

On Jul 11, 2008, at 3:49 PM, Dan Stowell wrote:

> No, I haven't, although I haven't looked in detail. Did anyone else
> try the patch on PPC, and/or with a firewire unit? Reports would be
> *very* helpful, in order to pin down what causes the issue.
>
> After setting my firewire box as input and my builtin as output, I
> started SC then ran:
>
>  s.boot;
>  {AudioIn.ar}.play
>
> and no sound, although there should be. (I do get sound if using
> either device exclusively.)
>
> It's definitely input that's missing rather than output, because
> SinOsc and friends can make sound, while something like this produces
> non-stop zeroes no matter what I do:
>
>  {Amplitude.kr(AudioIn.ar((1..8))).poll}.play
>
> Here's what the boot messages look like:
>
> Number of Devices: 2
>   0 : "Built-in Audio"
>   1 : "EDIROL FA-66 (3802)"
>
> "EDIROL FA-66 (3802)" Input Device
>   Streams: 6
>      0  channels 1
>      1  channels 1
>      2  channels 1
>      3  channels 1
>      4  channels 1
>      5  channels 1
>
> "Built-in Audio" Output Device
>   Streams: 1
>      0  channels 2
>
> mSafetyOffset 57
> mNumberBuffers 6
>  mDataByteSize 0 2048
>  mDataByteSize 1 2048
>  mDataByteSize 2 2048
>  mDataByteSize 3 2048
>  mDataByteSize 4 2048
>  mDataByteSize 5 2048
> <-SC_CoreAudioDriver::Setup world 00626880
> SC_AudioDriver: numSamples=512, sampleRate=44100.000000
> ->SC_CoreAudioDriver::DriverStart
> start   UseSeparateIO?: 1
> <-SC_CoreAudioDriver::DriverStart
> SuperCollider 3 server ready..
> notification is on
>
>
>
>
> 2008/7/11 Josh Parmenter <josh@...>:
>> Dan - were you able to get this working?
>>
>> josh
>>
>> On Jul 11, 2008, at 1:23 AM, Dan Stowell wrote:
>>
>>> Hi -
>>>
>>> This doesn't seem to work for me I'm afraid: the server claims to  
>>> boot
>>> happily with separate devices, but audio input doesn't actually
>>> happen. I'm on PPC, and testing by using Audio Midi Setup to set  
>>> input
>>> as firewire box and output as builtin, or vice versa. No difference
>>> between local and internal server in this case.
>>>
>>> Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play  
>>> actually
>>> plays sound through for them, with the patch?
>>>
>>> Dan
>>>
>>>
>>> 2008/7/10 Axel Balley <a.balley@...>:
>>>>
>>>> This might be a bit late to change directions, but I think I got  
>>>> support
>>>> for
>>>> separate input and output to work without dealing with agregate  
>>>> devices
>>>> at
>>>> all. The IOProc gets called separately for the input and the  
>>>> ouput device
>>>> when they are different. As usual, it's called just once when  
>>>> they're the
>>>> same. The node calculations are ran only during the output device
>>>> callback,
>>>> which uses the input data received during the last input device  
>>>> callback.
>>>> This works on my intel mac on both internal and local server.
>>>>
>>>> This patch works on rev 7669, that is before the previous patch  
>>>> using
>>>> aggregate devices was commited. Should we choose to go this  
>>>> direction,
>>>> Dan's
>>>> changes to the inDevice/outDevice server options will have to be  
>>>> put back
>>>> in, but that should be fairly quick to do.
>>>>
>>>> Advantages of this route :
>>>> - less code needed
>>>> - avoid aggregate devices API bugs
>>>> - a more predictable set of inputs and outputs when the user  
>>>> selects an
>>>> input device that also has output streams, and vice versa (the  
>>>> aggregate
>>>> devices would just mix everything, which is not necessary what  
>>>> the user
>>>> wants)
>>>>
>>>> I haven't run into syncronisation issues between input and  
>>>> output, please
>>>> let me know how this works on your end !
>>>>
>>>> Cheers,
>>>>
>>>> Axel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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/
>>
>
>
>
> --
> 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/

[Josh Parmenter]

OK... works for me on Intel with a PreSonus FireStudio and built-in  
speakers.

Josh

On Jul 11, 2008, at 3:49 PM, Dan Stowell wrote:

> No, I haven't, although I haven't looked in detail. Did anyone else
> try the patch on PPC, and/or with a firewire unit? Reports would be
> *very* helpful, in order to pin down what causes the issue.
>
> After setting my firewire box as input and my builtin as output, I
> started SC then ran:
>
>  s.boot;
>  {AudioIn.ar}.play
>
> and no sound, although there should be. (I do get sound if using
> either device exclusively.)
>
> It's definitely input that's missing rather than output, because
> SinOsc and friends can make sound, while something like this produces
> non-stop zeroes no matter what I do:
>
>  {Amplitude.kr(AudioIn.ar((1..8))).poll}.play
>
> Here's what the boot messages look like:
>
> Number of Devices: 2
>   0 : "Built-in Audio"
>   1 : "EDIROL FA-66 (3802)"
>
> "EDIROL FA-66 (3802)" Input Device
>   Streams: 6
>      0  channels 1
>      1  channels 1
>      2  channels 1
>      3  channels 1
>      4  channels 1
>      5  channels 1
>
> "Built-in Audio" Output Device
>   Streams: 1
>      0  channels 2
>
> mSafetyOffset 57
> mNumberBuffers 6
>  mDataByteSize 0 2048
>  mDataByteSize 1 2048
>  mDataByteSize 2 2048
>  mDataByteSize 3 2048
>  mDataByteSize 4 2048
>  mDataByteSize 5 2048
> <-SC_CoreAudioDriver::Setup world 00626880
> SC_AudioDriver: numSamples=512, sampleRate=44100.000000
> ->SC_CoreAudioDriver::DriverStart
> start   UseSeparateIO?: 1
> <-SC_CoreAudioDriver::DriverStart
> SuperCollider 3 server ready..
> notification is on
>
>
>
>
> 2008/7/11 Josh Parmenter <josh@...>:
>> Dan - were you able to get this working?
>>
>> josh
>>
>> On Jul 11, 2008, at 1:23 AM, Dan Stowell wrote:
>>
>>> Hi -
>>>
>>> This doesn't seem to work for me I'm afraid: the server claims to  
>>> boot
>>> happily with separate devices, but audio input doesn't actually
>>> happen. I'm on PPC, and testing by using Audio Midi Setup to set  
>>> input
>>> as firewire box and output as builtin, or vice versa. No difference
>>> between local and internal server in this case.
>>>
>>> Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play  
>>> actually
>>> plays sound through for them, with the patch?
>>>
>>> Dan
>>>
>>>
>>> 2008/7/10 Axel Balley <a.balley@...>:
>>>>
>>>> This might be a bit late to change directions, but I think I got  
>>>> support
>>>> for
>>>> separate input and output to work without dealing with agregate  
>>>> devices
>>>> at
>>>> all. The IOProc gets called separately for the input and the  
>>>> ouput device
>>>> when they are different. As usual, it's called just once when  
>>>> they're the
>>>> same. The node calculations are ran only during the output device
>>>> callback,
>>>> which uses the input data received during the last input device  
>>>> callback.
>>>> This works on my intel mac on both internal and local server.
>>>>
>>>> This patch works on rev 7669, that is before the previous patch  
>>>> using
>>>> aggregate devices was commited. Should we choose to go this  
>>>> direction,
>>>> Dan's
>>>> changes to the inDevice/outDevice server options will have to be  
>>>> put back
>>>> in, but that should be fairly quick to do.
>>>>
>>>> Advantages of this route :
>>>> - less code needed
>>>> - avoid aggregate devices API bugs
>>>> - a more predictable set of inputs and outputs when the user  
>>>> selects an
>>>> input device that also has output streams, and vice versa (the  
>>>> aggregate
>>>> devices would just mix everything, which is not necessary what  
>>>> the user
>>>> wants)
>>>>
>>>> I haven't run into syncronisation issues between input and  
>>>> output, please
>>>> let me know how this works on your end !
>>>>
>>>> Cheers,
>>>>
>>>> Axel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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/
>>
>
>
>
> --
> 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/

[Dan Stowell]

2008/7/11, Josh Parmenter <josh@...>:
> Like I mentioned... did you back up the revision before you built?

I checked out a fresh revision 7669, and then copied across some of
the code for requesting separate devices (as Axel suggested).

I've now gone back to a "pure" 7669+patch and actually it works fine.


>  OK... works for me on Intel with a PreSonus FireStudio and built-in speakers.

Thanks.

This patch is a much more elegant approach than the previous - in
particular, you get the input of the input device, and the output of
the output device, rather than getting both from both. Much more as
expected.

I propose to undo the previous patch, rev 7670, and commit this one.

This patch covers the "automatic" use of separate I/O, and this is the
main requirement (i.e. for Intel Macs to work in their default
configuration). How much demand is there for allowing separate I/O as
controlled from within SC?

Dan

>  On Jul 11, 2008, at 3:49 PM, Dan Stowell wrote:
>
>
> > No, I haven't, although I haven't looked in detail. Did anyone else
> > try the patch on PPC, and/or with a firewire unit? Reports would be
> > *very* helpful, in order to pin down what causes the issue.
> >
> > After setting my firewire box as input and my builtin as output, I
> > started SC then ran:
> >
> >  s.boot;
> >  {AudioIn.ar}.play
> >
> > and no sound, although there should be. (I do get sound if using
> > either device exclusively.)
> >
> > It's definitely input that's missing rather than output, because
> > SinOsc and friends can make sound, while something like this produces
> > non-stop zeroes no matter what I do:
> >
> >  {Amplitude.kr(AudioIn.ar((1..8))).poll}.play
> >
> > Here's what the boot messages look like:
> >
> > Number of Devices: 2
> >  0 : "Built-in Audio"
> >  1 : "EDIROL FA-66 (3802)"
> >
> > "EDIROL FA-66 (3802)" Input Device
> >  Streams: 6
> >     0  channels 1
> >     1  channels 1
> >     2  channels 1
> >     3  channels 1
> >     4  channels 1
> >     5  channels 1
> >
> > "Built-in Audio" Output Device
> >  Streams: 1
> >     0  channels 2
> >
> > mSafetyOffset 57
> > mNumberBuffers 6
> >  mDataByteSize 0 2048
> >  mDataByteSize 1 2048
> >  mDataByteSize 2 2048
> >  mDataByteSize 3 2048
> >  mDataByteSize 4 2048
> >  mDataByteSize 5 2048
> > <-SC_CoreAudioDriver::Setup world 00626880
> > SC_AudioDriver: numSamples=512, sampleRate=44100.000000
> > ->SC_CoreAudioDriver::DriverStart
> > start   UseSeparateIO?: 1
> > <-SC_CoreAudioDriver::DriverStart
> > SuperCollider 3 server ready..
> > notification is on
> >
> >
> >
> >
> > 2008/7/11 Josh Parmenter <josh@...>:
> >
> > > Dan - were you able to get this working?
> > >
> > > josh
> > >
> > > On Jul 11, 2008, at 1:23 AM, Dan Stowell wrote:
> > >
> > >
> > > > Hi -
> > > >
> > > > This doesn't seem to work for me I'm afraid: the server claims to boot
> > > > happily with separate devices, but audio input doesn't actually
> > > > happen. I'm on PPC, and testing by using Audio Midi Setup to set input
> > > > as firewire box and output as builtin, or vice versa. No difference
> > > > between local and internal server in this case.
> > > >
> > > > Can anyone (axel/josh/others) confirm that {AudioIn.ar}.play actually
> > > > plays sound through for them, with the patch?
> > > >
> > > > Dan
> > > >
> > > >
> > > > 2008/7/10 Axel Balley <a.balley@...>:
> > > >
> > > > >
> > > > > This might be a bit late to change directions, but I think I got
> support
> > > > > for
> > > > > separate input and output to work without dealing with agregate
> devices
> > > > > at
> > > > > all. The IOProc gets called separately for the input and the ouput
> device
> > > > > when they are different. As usual, it's called just once when
> they're the
> > > > > same. The node calculations are ran only during the output device
> > > > > callback,
> > > > > which uses the input data received during the last input device
> callback.
> > > > > This works on my intel mac on both internal and local server.
> > > > >
> > > > > This patch works on rev 7669, that is before the previous patch
> using
> > > > > aggregate devices was commited. Should we choose to go this
> direction,
> > > > > Dan's
> > > > > changes to the inDevice/outDevice server options will have to be put
> back
> > > > > in, but that should be fairly quick to do.
> > > > >
> > > > > Advantages of this route :
> > > > > - less code needed
> > > > > - avoid aggregate devices API bugs
> > > > > - a more predictable set of inputs and outputs when the user selects
> an
> > > > > input device that also has output streams, and vice versa (the
> aggregate
> > > > > devices would just mix everything, which is not necessary what the
> user
> > > > > wants)
> > > > >
> > > > > I haven't run into syncronisation issues between input and output,
> please
> > > > > let me know how this works on your end !
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Axel
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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/
> > >
> > >
> >
> >
> >
> > --
> > 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/MusicTe