Try not using OSC. Write one program that embeds both Csound and your
other sources of sound. Mix the sound from Csound with your other
sound before you send it to OpenAL.

You can access Csound's output buffer through the API in csoundGetSpout().

You can run Csound one kperiod at a time to synchronize with your
other sound sources. One will have to wait for the other. If your
other sound source is callback driven, set ksmps to your buffer size
and call csoundPerformKsmps in your callback then mix the sounds.

Hope this helps,
Mike

On Tue, May 8, 2012 at 8:28 AM, Anders Genell  wrote:
> Hi All!
>
> I have had some excellent help from some of you regarding issues with our
> unorthodox use of csound before, and here I go again with convoluted
> questions:
>
> Background:
> We use csound to generate sound for a driving simulator. It receives rpm,
> tourque and velocity as OSC messages and outputs engine sound and road
> noise.
> The output is sent (to localhost) as an udp stream via socksend (thank you
> jpff for the int16 fix!!) to a software we've written that uses OpenAL to
> spatialize the stream and mix with othe sounds (e.g. sound from surrounding
> traffic). We had a major problem getting things running until we figured out
> that even though csound does not output sound directly through the sound
> card, it needs to be synchronized with the soundcard clock for things to
> function. Wíthout it we get strange effects that sounds like a snippet of
> the stream is looped with a onset click/pop at every boundary. As OpenAL
> uses alsa for output, and hence locks the harware, we cannot use
> "-+rtaudio=alsa -odac=hw:0" in csound, but since we do not use the audio
> inputs, we can sync csound using "-+rtaudio=alsa -iadc=hw:0".
> We currently run this on Ubuntu 10.04, and our asound.conf contains 'plug'
> and 'ladspa' pcm layers to route channels and equalize the surround system
> (as the speaker placements in a car cabin are less than optimal).
>
> The problem:
> Intermittently when we run the program we get a runtime error from OpenAL
> saying "AL lib: alsa.c:417: mmap commit error: Broken pipe" and the sound
> dies. I don't know much about what mmap is or does, but it seems to have
> with direct access to the soundcard hardware buffers. Since we have the plug
> and ladspa layers in between, I was thinking that mmap is not the right
> thing to use, so I tried disabling it in alsoft.conf, but that caused csound
> not to start failing to initialize real-time audio (i.e. our input-channels
> sync fix).
>
> The question:
> My question is if it is possible either to sync csound to the sound card in
> some other way, not confliction with OpenAL, or if there is some way to
> avoid the need for syncing altogether?
>
>
>
> Best regards,
> Anders
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

If it's a different machine, OSC is the way to go. I didn't realize that.

Regards,
Mike

On Tue, May 8, 2012 at 9:52 AM, Anders Genell  wrote:
> Ah! Setting ksmps to the buffer size is a brilliant sync solution!
> We have been dabbling a bit with the API, but one thing we didn't quite
> figure out was how to gracefully stop our csound thread so that it allows
> for csound to release the hardware (we have a dummy 'run forever' score),
> but if ksmps and csoundGetSpout works out, then I guess that won't be a
> problem. Is there otherwise a nice way of letting csound release all its
> resources? Is there a return value to wait for?
>
> To mix before AL might be a problem since all different sources will need to
> have different positions in the AL sound space. Mixing the first will, I
> believe, only allow for one AL buffer and haence only one position?
>
> Not using OSC (why, btw?) should probably be possible, but we need to be
> able to pick up the values from the simulator kernel running on a different
> physical machine, and update the corresponding csound variables (in our case
> gkrpm, gkload and gkvel, i.e. global k-rate variables). I suppose there is
> some API function to update k-rate variables?
> Thanks!
>
> /Anders
> On Tue, May 8, 2012 at 3:21 PM, Michael Gogins 
> wrote:
>>
>> Try not using OSC. Write one program that embeds both Csound and your
>> other sources of sound. Mix the sound from Csound with your other
>> sound before you send it to OpenAL.
>>
>> You can access Csound's output buffer through the API in csoundGetSpout().
>>
>> You can run Csound one kperiod at a time to synchronize with your
>> other sound sources. One will have to wait for the other. If your
>> other sound source is callback driven, set ksmps to your buffer size
>> and call csoundPerformKsmps in your callback then mix the sounds.
>>
>> Hope this helps,
>> Mike
>>
>> On Tue, May 8, 2012 at 8:28 AM, Anders Genell 
>> wrote:
>> > Hi All!
>> >
>> > I have had some excellent help from some of you regarding issues with
>> > our
>> > unorthodox use of csound before, and here I go again with convoluted
>> > questions:
>> >
>> > Background:
>> > We use csound to generate sound for a driving simulator. It receives
>> > rpm,
>> > tourque and velocity as OSC messages and outputs engine sound and road
>> > noise.
>> > The output is sent (to localhost) as an udp stream via socksend (thank
>> > you
>> > jpff for the int16 fix!!) to a software we've written that uses OpenAL
>> > to
>> > spatialize the stream and mix with othe sounds (e.g. sound from
>> > surrounding
>> > traffic). We had a major problem getting things running until we figured
>> > out
>> > that even though csound does not output sound directly through the sound
>> > card, it needs to be synchronized with the soundcard clock for things to
>> > function. Wíthout it we get strange effects that sounds like a snippet
>> > of
>> > the stream is looped with a onset click/pop at every boundary. As OpenAL
>> > uses alsa for output, and hence locks the harware, we cannot use
>> > "-+rtaudio=alsa -odac=hw:0" in csound, but since we do not use the audio
>> > inputs, we can sync csound using "-+rtaudio=alsa -iadc=hw:0".
>> > We currently run this on Ubuntu 10.04, and our asound.conf contains
>> > 'plug'
>> > and 'ladspa' pcm layers to route channels and equalize the surround
>> > system
>> > (as the speaker placements in a car cabin are less than optimal).
>> >
>> > The problem:
>> > Intermittently when we run the program we get a runtime error from
>> > OpenAL
>> > saying "AL lib: alsa.c:417: mmap commit error: Broken pipe" and the
>> > sound
>> > dies. I don't know much about what mmap is or does, but it seems to have
>> > with direct access to the soundcard hardware buffers. Since we have the
>> > plug
>> > and ladspa layers in between, I was thinking that mmap is not the right
>> > thing to use, so I tried disabling it in alsoft.conf, but that caused
>> > csound
>> > not to start failing to initialize real-time audio (i.e. our
>> > input-channels
>> > sync fix).
>> >
>> > The question:
>> > My question is if it is possible either to sync csound to the sound card
>> > in
>> > some other way, not confliction with OpenAL, or if there is some way to
>> > avoid the need for syncing altogether?
>> >
>> >
>> >
>> > Best regards,
>> > Anders
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Hi,

Yes, setting ksmps to the same value can help with synchronization a
bit, but since you are talking about two separate pieces of hardware,
there will always be clock drift. If the ksmps is not too small, and
the cards' clocks are fairly stable, you will have only occasional
frames with two or no messages due to the jitter. It might even happen
that you have no problems, but when they come they will come a lot
because the blocks will be close to the boundaries (when the block
boundaries are close between both instances). So you need to provision
for that case. The best would be to sync the hardware using wordclock.
Then you would only have network jitter to deal with, but if your
network is stable and ksmps is big enough, you should have no problem.

Cheers,
Andrés

On Tue, May 8, 2012 at 2:52 PM, Anders Genell  wrote:
> Ah! Setting ksmps to the buffer size is a brilliant sync solution!
> We have been dabbling a bit with the API, but one thing we didn't quite
> figure out was how to gracefully stop our csound thread so that it allows
> for csound to release the hardware (we have a dummy 'run forever' score),
> but if ksmps and csoundGetSpout works out, then I guess that won't be a
> problem. Is there otherwise a nice way of letting csound release all its
> resources? Is there a return value to wait for?
>
> To mix before AL might be a problem since all different sources will need to
> have different positions in the AL sound space. Mixing the first will, I
> believe, only allow for one AL buffer and haence only one position?
>
> Not using OSC (why, btw?) should probably be possible, but we need to be
> able to pick up the values from the simulator kernel running on a different
> physical machine, and update the corresponding csound variables (in our case
> gkrpm, gkload and gkvel, i.e. global k-rate variables). I suppose there is
> some API function to update k-rate variables?
> Thanks!
>
> /Anders
> On Tue, May 8, 2012 at 3:21 PM, Michael Gogins 
> wrote:
>>
>> Try not using OSC. Write one program that embeds both Csound and your
>> other sources of sound. Mix the sound from Csound with your other
>> sound before you send it to OpenAL.
>>
>> You can access Csound's output buffer through the API in csoundGetSpout().
>>
>> You can run Csound one kperiod at a time to synchronize with your
>> other sound sources. One will have to wait for the other. If your
>> other sound source is callback driven, set ksmps to your buffer size
>> and call csoundPerformKsmps in your callback then mix the sounds.
>>
>> Hope this helps,
>> Mike
>>
>> On Tue, May 8, 2012 at 8:28 AM, Anders Genell 
>> wrote:
>> > Hi All!
>> >
>> > I have had some excellent help from some of you regarding issues with
>> > our
>> > unorthodox use of csound before, and here I go again with convoluted
>> > questions:
>> >
>> > Background:
>> > We use csound to generate sound for a driving simulator. It receives
>> > rpm,
>> > tourque and velocity as OSC messages and outputs engine sound and road
>> > noise.
>> > The output is sent (to localhost) as an udp stream via socksend (thank
>> > you
>> > jpff for the int16 fix!!) to a software we've written that uses OpenAL
>> > to
>> > spatialize the stream and mix with othe sounds (e.g. sound from
>> > surrounding
>> > traffic). We had a major problem getting things running until we figured
>> > out
>> > that even though csound does not output sound directly through the sound
>> > card, it needs to be synchronized with the soundcard clock for things to
>> > function. Wíthout it we get strange effects that sounds like a snippet
>> > of
>> > the stream is looped with a onset click/pop at every boundary. As OpenAL
>> > uses alsa for output, and hence locks the harware, we cannot use
>> > "-+rtaudio=alsa -odac=hw:0" in csound, but since we do not use the audio
>> > inputs, we can sync csound using "-+rtaudio=alsa -iadc=hw:0".
>> > We currently run this on Ubuntu 10.04, and our asound.conf contains
>> > 'plug'
>> > and 'ladspa' pcm layers to route channels and equalize the surround
>> > system
>> > (as the speaker placements in a car cabin are less than optimal).
>> >
>> > The problem:
>> > Intermittently when we run the program we get a runtime error from
>> > OpenAL
>> > saying "AL lib: alsa.c:417: mmap commit error: Broken pipe" and the
>> > sound
>> > dies. I don't know much about what mmap is or does, but it seems to have
>> > with direct access to the soundcard hardware buffers. Since we have the
>> > plug
>> > and ladspa layers in between, I was thinking that mmap is not the right
>> > thing to use, so I tried disabling it in alsoft.conf, but that caused
>> > csound
>> > not to start failing to initialize real-time audio (i.e. our
>> > input-channels
>> > sync fix).
>> >
>> > The question:
>> > My question is if it is possible either to sync csound to the sound card
>> > in
>> > some other way, not confliction with OpenAL, or if there is some way to
>> > avoid the need for syncing altogether?
>> >
>> >
>> >
>> > Best regards,
>> > Anders
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>

Ah, I am sorry to have caused such confusion - I'll try to clarify:


csound and OpenAL is on the same physical hardware so setting ksmps to the AL buffer size should do the trick (I believe). 

The source of the Open Sound Control messages is on a different physical machine, but that will not affect sync, as I understand it - either there is a new OSC message at a performKsmps() or there old one is used. 

You explanation does clarify why we had the sync problem initially, though. Without any connection to the sound hardware, I suppose csound syncs to the CPU clock frequency, and I suppose there could be the same drift between those?

Is it possible to let csound or OpenAL access the word clock somehow without locking the audio ports of the sound card?


Thanks for the reply!


/A



9 maj 2012 kl. 08:56 skrev Andres Cabrera :

> Hi,
> 
> Yes, setting ksmps to the same value can help with synchronization a
> bit, but since you are talking about two separate pieces of hardware,
> there will always be clock drift. If the ksmps is not too small, and
> the cards' clocks are fairly stable, you will have only occasional
> frames with two or no messages due to the jitter. It might even happen
> that you have no problems, but when they come they will come a lot
> because the blocks will be close to the boundaries (when the block
> boundaries are close between both instances). So you need to provision
> for that case. The best would be to sync the hardware using wordclock.
> Then you would only have network jitter to deal with, but if your
> network is stable and ksmps is big enough, you should have no problem.
> 
> Cheers,
> Andrés
> 
> On Tue, May 8, 2012 at 2:52 PM, Anders Genell  wrote:
>> Ah! Setting ksmps to the buffer size is a brilliant sync solution!
>> We have been dabbling a bit with the API, but one thing we didn't quite
>> figure out was how to gracefully stop our csound thread so that it allows
>> for csound to release the hardware (we have a dummy 'run forever' score),
>> but if ksmps and csoundGetSpout works out, then I guess that won't be a
>> problem. Is there otherwise a nice way of letting csound release all its
>> resources? Is there a return value to wait for?
>> 
>> To mix before AL might be a problem since all different sources will need to
>> have different positions in the AL sound space. Mixing the first will, I
>> believe, only allow for one AL buffer and haence only one position?
>> 
>> Not using OSC (why, btw?) should probably be possible, but we need to be
>> able to pick up the values from the simulator kernel running on a different
>> physical machine, and update the corresponding csound variables (in our case
>> gkrpm, gkload and gkvel, i.e. global k-rate variables). I suppose there is
>> some API function to update k-rate variables?
>> Thanks!
>> 
>> /Anders
>> On Tue, May 8, 2012 at 3:21 PM, Michael Gogins 
>> wrote:
>>> 
>>> Try not using OSC. Write one program that embeds both Csound and your
>>> other sources of sound. Mix the sound from Csound with your other
>>> sound before you send it to OpenAL.
>>> 
>>> You can access Csound's output buffer through the API in csoundGetSpout().
>>> 
>>> You can run Csound one kperiod at a time to synchronize with your
>>> other sound sources. One will have to wait for the other. If your
>>> other sound source is callback driven, set ksmps to your buffer size
>>> and call csoundPerformKsmps in your callback then mix the sounds.
>>> 
>>> Hope this helps,
>>> Mike
>>> 
>>> On Tue, May 8, 2012 at 8:28 AM, Anders Genell 
>>> wrote:
>>>> Hi All!
>>>> 
>>>> I have had some excellent help from some of you regarding issues with
>>>> our
>>>> unorthodox use of csound before, and here I go again with convoluted
>>>> questions:
>>>> 
>>>> Background:
>>>> We use csound to generate sound for a driving simulator. It receives
>>>> rpm,
>>>> tourque and velocity as OSC messages and outputs engine sound and road
>>>> noise.
>>>> The output is sent (to localhost) as an udp stream via socksend (thank
>>>> you
>>>> jpff for the int16 fix!!) to a software we've written that uses OpenAL
>>>> to
>>>> spatialize the stream and mix with othe sounds (e.g. sound from
>>>> surrounding
>>>> traffic). We had a major problem getting things running until we figured
>>>> out
>>>> that even though csound does not output sound directly through the sound
>>>> card, it needs to be synchronized with the soundcard clock for things to
>>>> function. Wíthout it we get strange effects that sounds like a snippet
>>>> of
>>>> the stream is looped with a onset click/pop at every boundary. As OpenAL
>>>> uses alsa for output, and hence locks the harware, we cannot use
>>>> "-+rtaudio=alsa -odac=hw:0" in csound, but since we do not use the audio
>>>> inputs, we can sync csound using "-+rtaudio=alsa -iadc=hw:0".
>>>> We currently run this on Ubuntu 10.04, and our asound.conf contains
>>>> 'plug'
>>>> and 'ladspa' pcm layers to route channels and equalize the surround
>>>> system
>>>> (as the speaker placements in a car cabin are less than optimal).
>>>> 
>>>> The problem:
>>>> Intermittently when we run the program we get a runtime error from
>>>> OpenAL
>>>> saying "AL lib: alsa.c:417: mmap commit error: Broken pipe" and the
>>>> sound
>>>> dies. I don't know much about what mmap is or does, but it seems to have
>>>> with direct access to the soundcard hardware buffers. Since we have the
>>>> plug
>>>> and ladspa layers in between, I was thinking that mmap is not the right
>>>> thing to use, so I tried disabling it in alsoft.conf, but that caused
>>>> csound
>>>> not to start failing to initialize real-time audio (i.e. our
>>>> input-channels
>>>> sync fix).
>>>> 
>>>> The question:
>>>> My question is if it is possible either to sync csound to the sound card
>>>> in
>>>> some other way, not confliction with OpenAL, or if there is some way to
>>>> avoid the need for syncing altogether?
>>>> 
>>>> 
>>>> 
>>>> Best regards,
>>>> Anders
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>> 
>> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Hi

On Wed, May 9, 2012 at 8:16 AM, Anders Genell  wrote:
> Is it possible to let csound or OpenAL access the word clock somehow without locking the audio ports of the sound card?

No I don't think so. This is a hardware thing.

Csound can only run in realtime driven by a sound card, so it will
never sync to the CPU in that way. Maybe you were using a different
card (the built in audio chip, for example).

Cheers,
Andrés

Well, we were actually using an alsa dummy PCM - a null device - when we had the sync problem. Obviously it does not sync with the resident hardware. The only audio chip present in the machine (it is a rack server motherboard, so no onboard audio) is the RME card. 

So maybe csound was syncing with the CPU through the dummy device?

Regards,
Anders


9 maj 2012 kl. 09:31 skrev Andres Cabrera :

> Hi
> 
> On Wed, May 9, 2012 at 8:16 AM, Anders Genell  wrote:
>> Is it possible to let csound or OpenAL access the word clock somehow without locking the audio ports of the sound card?
> 
> No I don't think so. This is a hardware thing.
> 
> Csound can only run in realtime driven by a sound card, so it will
> never sync to the CPU in that way. Maybe you were using a different
> card (the built in audio chip, for example).
> 
> Cheers,
> Andrés
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Hi,

Yes, then you are right, it was synced to the CPU clock. But I would
suspect not very directly, and probably these dummy devices have very
inaccurate timing. You might actually get better timing just putting
any sound card in there and using it as output.

Cheers,
Andrés

On Wed, May 9, 2012 at 11:28 AM, Anders Genell  wrote:
> Well, we were actually using an alsa dummy PCM - a null device - when we had the sync problem. Obviously it does not sync with the resident hardware. The only audio chip present in the machine (it is a rack server motherboard, so no onboard audio) is the RME card.
>
> So maybe csound was syncing with the CPU through the dummy device?
>
> Regards,
> Anders
>
>
> 9 maj 2012 kl. 09:31 skrev Andres Cabrera :
>
>> Hi
>>
>> On Wed, May 9, 2012 at 8:16 AM, Anders Genell  wrote:
>>> Is it possible to let csound or OpenAL access the word clock somehow without locking the audio ports of the sound card?
>>
>> No I don't think so. This is a hardware thing.
>>
>> Csound can only run in realtime driven by a sound card, so it will
>> never sync to the CPU in that way. Maybe you were using a different
>> card (the built in audio chip, for example).
>>
>> Cheers,
>> Andrés
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Hm. Maybe getting the very simplest of sound cards that allows word clock sync would be a solution...

Would it otherwise be possible to add support in csound to sync to a sound card without blocking the audio I/O?
Something like relate absolute performance time to the timestamp in /proc/asound/card0/pcmp0/sub0/status ?

I suppose doing it via ksmps vs buffer size and csoundPerformKsmps() might be a more convenient case...


I still wonder though, why there is sync problems when streaming the csound output as UDP (socksend) to a separate software? Shouldn't the receiving software just pick audio from the incoming packets and play in sync with whatever sound card is being used? Why should csound sync be needed?
How does it work when csound socksends audio over network to another physical machine where csound sockreceivs and plays audio? I believe John mentioned these opcodes were developed for the OLPC-project...


Regards,
Anders

9 maj 2012 kl. 12:39 skrev Andres Cabrera :

> Hi,
> 
> Yes, then you are right, it was synced to the CPU clock. But I would
> suspect not very directly, and probably these dummy devices have very
> inaccurate timing. You might actually get better timing just putting
> any sound card in there and using it as output.
> 
> Cheers,
> Andrés
> 
> On Wed, May 9, 2012 at 11:28 AM, Anders Genell  wrote:
>> Well, we were actually using an alsa dummy PCM - a null device - when we had the sync problem. Obviously it does not sync with the resident hardware. The only audio chip present in the machine (it is a rack server motherboard, so no onboard audio) is the RME card.
>> 
>> So maybe csound was syncing with the CPU through the dummy device?
>> 
>> Regards,
>> Anders
>> 
>> 
>> 9 maj 2012 kl. 09:31 skrev Andres Cabrera :
>> 
>>> Hi
>>> 
>>> On Wed, May 9, 2012 at 8:16 AM, Anders Genell  wrote:
>>>> Is it possible to let csound or OpenAL access the word clock somehow without locking the audio ports of the sound card?
>>> 
>>> No I don't think so. This is a hardware thing.
>>> 
>>> Csound can only run in realtime driven by a sound card, so it will
>>> never sync to the CPU in that way. Maybe you were using a different
>>> card (the built in audio chip, for example).
>>> 
>>> Cheers,
>>> Andrés
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

The receiving software may or may not have a queue.

The safe way to do this is to put a first in, first out queue in the
receiver, and let it back up for several buffers worth of audio. Then
when the receiver receives its call for a buffer, it dequeues the
oldest buffer and goes back to wait for the next call for a buffer. If
the sender gets ahead of the receiver, buffers pile up in the queue.
If the receiver gets ahead of the sender for a buffer or so, the queue
shrinks but it should be safe for a call or two. This is a "loosely
coupled" system.

Such queues are common in the "upper half" of device drivers.

Regards,
Mike

On Wed, May 9, 2012 at 8:37 AM, Anders Genell  wrote:
> Hm. Maybe getting the very simplest of sound cards that allows word clock sync would be a solution...
>
> Would it otherwise be possible to add support in csound to sync to a sound card without blocking the audio I/O?
> Something like relate absolute performance time to the timestamp in /proc/asound/card0/pcmp0/sub0/status ?
>
> I suppose doing it via ksmps vs buffer size and csoundPerformKsmps() might be a more convenient case...
>
>
> I still wonder though, why there is sync problems when streaming the csound output as UDP (socksend) to a separate software? Shouldn't the receiving software just pick audio from the incoming packets and play in sync with whatever sound card is being used? Why should csound sync be needed?
> How does it work when csound socksends audio over network to another physical machine where csound sockreceivs and plays audio? I believe John mentioned these opcodes were developed for the OLPC-project...
>
>
> Regards,
> Anders
>
> 9 maj 2012 kl. 12:39 skrev Andres Cabrera :
>
>> Hi,
>>
>> Yes, then you are right, it was synced to the CPU clock. But I would
>> suspect not very directly, and probably these dummy devices have very
>> inaccurate timing. You might actually get better timing just putting
>> any sound card in there and using it as output.
>>
>> Cheers,
>> Andrés
>>
>> On Wed, May 9, 2012 at 11:28 AM, Anders Genell  wrote:
>>> Well, we were actually using an alsa dummy PCM - a null device - when we had the sync problem. Obviously it does not sync with the resident hardware. The only audio chip present in the machine (it is a rack server motherboard, so no onboard audio) is the RME card.
>>>
>>> So maybe csound was syncing with the CPU through the dummy device?
>>>
>>> Regards,
>>> Anders
>>>
>>>
>>> 9 maj 2012 kl. 09:31 skrev Andres Cabrera :
>>>
>>>> Hi
>>>>
>>>> On Wed, May 9, 2012 at 8:16 AM, Anders Genell  wrote:
>>>>> Is it possible to let csound or OpenAL access the word clock somehow without locking the audio ports of the sound card?
>>>>
>>>> No I don't think so. This is a hardware thing.
>>>>
>>>> Csound can only run in realtime driven by a sound card, so it will
>>>> never sync to the CPU in that way. Maybe you were using a different
>>>> card (the built in audio chip, for example).
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Aha! From what I understand about JACK that they use a FIFO type ring buffer like this, and so does csound, I assume, with the -b versus -B command line flags etc?

Oh, another question related to csoundSpout: how are the frames handled? That is, how do we access different output channels? Are they interleaved as 32 bits for each channel continuously within each buffer?
How should one in that case relate the OpenAL buffer size, which I assume related to the number of channels in the output of OpenAL - in our case 8 channels for a 7.1 surround system - to ksmps which handles audio from nchnls number of channels - in our case currently one, but will likely be at least 5 in the future?

Should we do something like ksmps/nchnls = ALbuffer/8?

Regards,

Anders



9 maj 2012 kl. 14:49 skrev Michael Gogins :

> The receiving software may or may not have a queue.
> 
> The safe way to do this is to put a first in, first out queue in the
> receiver, and let it back up for several buffers worth of audio. Then
> when the receiver receives its call for a buffer, it dequeues the
> oldest buffer and goes back to wait for the next call for a buffer. If
> the sender gets ahead of the receiver, buffers pile up in the queue.
> If the receiver gets ahead of the sender for a buffer or so, the queue
> shrinks but it should be safe for a call or two. This is a "loosely
> coupled" system.
> 
> Such queues are common in the "upper half" of device drivers.
> 
> Regards,
> Mike
> 
> On Wed, May 9, 2012 at 8:37 AM, Anders Genell  wrote:
>> Hm. Maybe getting the very simplest of sound cards that allows word clock sync would be a solution...
>> 
>> Would it otherwise be possible to add support in csound to sync to a sound card without blocking the audio I/O?
>> Something like relate absolute performance time to the timestamp in /proc/asound/card0/pcmp0/sub0/status ?
>> 
>> I suppose doing it via ksmps vs buffer size and csoundPerformKsmps() might be a more convenient case...
>> 
>> 
>> I still wonder though, why there is sync problems when streaming the csound output as UDP (socksend) to a separate software? Shouldn't the receiving software just pick audio from the incoming packets and play in sync with whatever sound card is being used? Why should csound sync be needed?
>> How does it work when csound socksends audio over network to another physical machine where csound sockreceivs and plays audio? I believe John mentioned these opcodes were developed for the OLPC-project...
>> 
>> 
>> Regards,
>> Anders
>> 
>> 9 maj 2012 kl. 12:39 skrev Andres Cabrera :
>> 
>>> Hi,
>>> 
>>> Yes, then you are right, it was synced to the CPU clock. But I would
>>> suspect not very directly, and probably these dummy devices have very
>>> inaccurate timing. You might actually get better timing just putting
>>> any sound card in there and using it as output.
>>> 
>>> Cheers,
>>> Andrés
>>> 
>>> On Wed, May 9, 2012 at 11:28 AM, Anders Genell  wrote:
>>>> Well, we were actually using an alsa dummy PCM - a null device - when we had the sync problem. Obviously it does not sync with the resident hardware. The only audio chip present in the machine (it is a rack server motherboard, so no onboard audio) is the RME card.
>>>> 
>>>> So maybe csound was syncing with the CPU through the dummy device?
>>>> 
>>>> Regards,
>>>> Anders
>>>> 
>>>> 
>>>> 9 maj 2012 kl. 09:31 skrev Andres Cabrera :
>>>> 
>>>>> Hi
>>>>> 
>>>>> On Wed, May 9, 2012 at 8:16 AM, Anders Genell  wrote:
>>>>>> Is it possible to let csound or OpenAL access the word clock somehow without locking the audio ports of the sound card?
>>>>> 
>>>>> No I don't think so. This is a hardware thing.
>>>>> 
>>>>> Csound can only run in realtime driven by a sound card, so it will
>>>>> never sync to the CPU in that way. Maybe you were using a different
>>>>> card (the built in audio chip, for example).
>>>>> 
>>>>> Cheers,
>>>>> Andrés
>>>>> 
>>>>> 
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>> 
>>>> 
>>>> 
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>> 
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
> 
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>