Dear list!

I send this to the dev list as it could be seen as something of a feature request, or at least concerns the innards of csound. It could on the other hand just as easily be seen as completely off topic, and for that I apologize. 

I have asked something similar before, but can't just wrap my brain around the very innards of digital audio. 

The short version: Could csound feature a dummy audio clock synced to the audio hardware but not locking the hardware up?

The long: I cannot on a satisfactory level make myself understand the mysteries of syncing digital audio. 

When csound generates real-time audio, it is synced to the sound card clock, right?

Does that mean that 44100 Hz is actually 44100.2446 Hz or so on one machine and 44100.5430 on another?

So, if we let csound use a dummy alsa device when on Linux, it will scale down the CPU freq to something close to 44100 Hz, and will be out of sync with the sound card clock. 

But how does then writing and playing sound files work? Is the sound file also 44100.2446 Hz? Would there not be problems when playing the file on another machine then?

And what about streaming audio? There are web radio streams that seem fine for long durations. And there is of course voice over ip and the like. How does that fit in the syncing scheme? 

I think Victor suggested to wrap the csound execution in a PerformKsmps-loop and have the software that is synced with the sound card call the loop when new audio data is needed. But the PerformKsmps need a csd, which needs to be synced to some hardware or other, right?

Sorry to come across as particularly thick headed, but this has been eating me for some time. 

Regards,
Anders


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Csound just produces SR frames/sec of audio.  When it is running out to DAC, it just pumps out these to the hardware, and let it deal with it. The HW 
will then do the conversion and create the analog signal at its output. Csound will just count how many frames it has output and keep its internal clock
based on that. This means that effectively it will produce the samples at a rate requested by the HW (if Csound is running faster, it will just have to wait
until the HW needs more samples, but if it is running slower, there will be dropouts). 

When writing to disk, it just puts the SR frames to disk; then is up to the playback program to send these to HW. With streaming, there is probably a
certain amount of buffering, and you are getting the data in some compressed form that is put in memory locally, converted to raw samples and
then played back. Because of this, it is not that different from playing back samples off a file. If the buffering is not enough, you will get the odd
breakdown in the audio. There is no sample-to-sample synchronisation, and there is a great latency between the audio being produced and
it being played back.

Victor
On 15 Jul 2013, at 08:02, Anders Genell wrote:

> Dear list!
> 
> I send this to the dev list as it could be seen as something of a feature request, or at least concerns the innards of csound. It could on the other hand just as easily be seen as completely off topic, and for that I apologize. 
> 
> I have asked something similar before, but can't just wrap my brain around the very innards of digital audio. 
> 
> The short version: Could csound feature a dummy audio clock synced to the audio hardware but not locking the hardware up?
> 
> The long: I cannot on a satisfactory level make myself understand the mysteries of syncing digital audio. 
> 
> When csound generates real-time audio, it is synced to the sound card clock, right?
> 
> Does that mean that 44100 Hz is actually 44100.2446 Hz or so on one machine and 44100.5430 on another?
> 
> So, if we let csound use a dummy alsa device when on Linux, it will scale down the CPU freq to something close to 44100 Hz, and will be out of sync with the sound card clock. 
> 
> But how does then writing and playing sound files work? Is the sound file also 44100.2446 Hz? Would there not be problems when playing the file on another machine then?
> 
> And what about streaming audio? There are web radio streams that seem fine for long durations. And there is of course voice over ip and the like. How does that fit in the syncing scheme? 
> 
> I think Victor suggested to wrap the csound execution in a PerformKsmps-loop and have the software that is synced with the sound card call the loop when new audio data is needed. But the PerformKsmps need a csd, which needs to be synced to some hardware or other, right?
> 
> Sorry to come across as particularly thick headed, but this has been eating me for some time. 
> 
> Regards,
> Anders
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thank you Victor!!

So in essence running csound in a performksmps loop called from a host program synced to the hw should be the same as running csound out to dac?
But what flags should be set in the csd then? If we omit -odac we should avoid csound syncing to hw by itself, but what other options are there? We need to have some version or real-time, since we read OSC input to alter sound in real time. Some latency is ok, but not as much as several hundred milliseconds.

Otherwise, running with a dummy alsa device and sending an udp stream (as we do now) to the playback program should work as long as we have enough buffering?

Regards,
/Anders

On Mon, 15 Jul 2013 10:14:56 +0100
Victor Lazzarini  wrote:

> Csound just produces SR frames/sec of audio.  When it is running out to DAC, it just pumps out these to the hardware, and let it deal with it. The HW 
> will then do the conversion and create the analog signal at its output. Csound will just count how many frames it has output and keep its internal clock
> based on that. This means that effectively it will produce the samples at a rate requested by the HW (if Csound is running faster, it will just have to wait
> until the HW needs more samples, but if it is running slower, there will be dropouts). 
> 
> When writing to disk, it just puts the SR frames to disk; then is up to the playback program to send these to HW. With streaming, there is probably a
> certain amount of buffering, and you are getting the data in some compressed form that is put in memory locally, converted to raw samples and
> then played back. Because of this, it is not that different from playing back samples off a file. If the buffering is not enough, you will get the odd
> breakdown in the audio. There is no sample-to-sample synchronisation, and there is a great latency between the audio being produced and
> it being played back.
> 
> Victor
> On 15 Jul 2013, at 08:02, Anders Genell wrote:
> 
> > Dear list!
> > 
> > I send this to the dev list as it could be seen as something of a feature request, or at least concerns the innards of csound. It could on the other hand just as easily be seen as completely off topic, and for that I apologize. 
> > 
> > I have asked something similar before, but can't just wrap my brain around the very innards of digital audio. 
> > 
> > The short version: Could csound feature a dummy audio clock synced to the audio hardware but not locking the hardware up?
> > 
> > The long: I cannot on a satisfactory level make myself understand the mysteries of syncing digital audio. 
> > 
> > When csound generates real-time audio, it is synced to the sound card clock, right?
> > 
> > Does that mean that 44100 Hz is actually 44100.2446 Hz or so on one machine and 44100.5430 on another?
> > 
> > So, if we let csound use a dummy alsa device when on Linux, it will scale down the CPU freq to something close to 44100 Hz, and will be out of sync with the sound card clock. 
> > 
> > But how does then writing and playing sound files work? Is the sound file also 44100.2446 Hz? Would there not be problems when playing the file on another machine then?
> > 
> > And what about streaming audio? There are web radio streams that seem fine for long durations. And there is of course voice over ip and the like. How does that fit in the syncing scheme? 
> > 
> > I think Victor suggested to wrap the csound execution in a PerformKsmps-loop and have the software that is synced with the sound card call the loop when new audio data is needed. But the PerformKsmps need a csd, which needs to be synced to some hardware or other, right?
> > 
> > Sorry to come across as particularly thick headed, but this has been eating me for some time. 
> > 
> > Regards,
> > Anders
> > 
> > 
> > ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
Anders Genell 

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, I have used jack quite successfully in other cases, but in this particular case the output goes through OpenAL, which unfortunately is not jack aware. I have posted a request to the jack dev-list about getting a jack io in OpenAL, and got a kind reply back, but no real promise or ETA.

I am battling our developers to make them hack together the ksmps loop solution, but they have been hesitant as they don't have any previous experience with the csound api, and learning to get it up and running will take time that we/they don't have (funding for). 

If I can succeed in some of my upcoming applications for funding, there might be a better chance, and then I think we'll aim for that solution. I suppose chnset/get is the way to go then?

Regards,
/Anders

On Mon, 15 Jul 2013 06:13:33 -0700
Justin Smith  wrote:

> UDP is going to introduce significant and unpredictable latencies. Do the
> sound generation and playback have to be on separate devices? If not, this
> is exactly the sort of thing jack was designed for, and it does it quite
> well.
> 
> 
> On Mon, Jul 15, 2013 at 4:21 AM, Anders Genell wrote:
> 
> > Thank you Victor!!
> >
> > So in essence running csound in a performksmps loop called from a host
> > program synced to the hw should be the same as running csound out to dac?
> > But what flags should be set in the csd then? If we omit -odac we should
> > avoid csound syncing to hw by itself, but what other options are there? We
> > need to have some version or real-time, since we read OSC input to alter
> > sound in real time. Some latency is ok, but not as much as several hundred
> > milliseconds.
> >
> > Otherwise, running with a dummy alsa device and sending an udp stream (as
> > we do now) to the playback program should work as long as we have enough
> > buffering?
> >
> > Regards,
> > /Anders
> >
> > On Mon, 15 Jul 2013 10:14:56 +0100
> > Victor Lazzarini  wrote:
> >
> > > Csound just produces SR frames/sec of audio.  When it is running out to
> > DAC, it just pumps out these to the hardware, and let it deal with it. The
> > HW
> > > will then do the conversion and create the analog signal at its output.
> > Csound will just count how many frames it has output and keep its internal
> > clock
> > > based on that. This means that effectively it will produce the samples
> > at a rate requested by the HW (if Csound is running faster, it will just
> > have to wait
> > > until the HW needs more samples, but if it is running slower, there will
> > be dropouts).
> > >
> > > When writing to disk, it just puts the SR frames to disk; then is up to
> > the playback program to send these to HW. With streaming, there is probably
> > a
> > > certain amount of buffering, and you are getting the data in some
> > compressed form that is put in memory locally, converted to raw samples and
> > > then played back. Because of this, it is not that different from playing
> > back samples off a file. If the buffering is not enough, you will get the
> > odd
> > > breakdown in the audio. There is no sample-to-sample synchronisation,
> > and there is a great latency between the audio being produced and
> > > it being played back.
> > >
> > > Victor
> > > On 15 Jul 2013, at 08:02, Anders Genell wrote:
> > >
> > > > Dear list!
> > > >
> > > > I send this to the dev list as it could be seen as something of a
> > feature request, or at least concerns the innards of csound. It could on
> > the other hand just as easily be seen as completely off topic, and for that
> > I apologize.
> > > >
> > > > I have asked something similar before, but can't just wrap my brain
> > around the very innards of digital audio.
> > > >
> > > > The short version: Could csound feature a dummy audio clock synced to
> > the audio hardware but not locking the hardware up?
> > > >
> > > > The long: I cannot on a satisfactory level make myself understand the
> > mysteries of syncing digital audio.
> > > >
> > > > When csound generates real-time audio, it is synced to the sound card
> > clock, right?
> > > >
> > > > Does that mean that 44100 Hz is actually 44100.2446 Hz or so on one
> > machine and 44100.5430 on another?
> > > >
> > > > So, if we let csound use a dummy alsa device when on Linux, it will
> > scale down the CPU freq to something close to 44100 Hz, and will be out of
> > sync with the sound card clock.
> > > >
> > > > But how does then writing and playing sound files work? Is the sound
> > file also 44100.2446 Hz? Would there not be problems when playing the file
> > on another machine then?
> > > >
> > > > And what about streaming audio? There are web radio streams that seem
> > fine for long durations. And there is of course voice over ip and the like.
> > How does that fit in the syncing scheme?
> > > >
> > > > I think Victor suggested to wrap the csound execution in a
> > PerformKsmps-loop and have the software that is synced with the sound card
> > call the loop when new audio data is needed. But the PerformKsmps need a
> > csd, which needs to be synced to some hardware or other, right?
> > > >
> > > > Sorry to come across as particularly thick headed, but this has been
> > eating me for some time.
> > > >
> > > > Regards,
> > > > Anders
> > > >
> > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > See everything from the browser to the database with AppDynamics
> > > > Get end-to-end visibility with application monitoring from AppDynamics
> > > > Isolate bottlenecks and diagnose root cause in seconds.
> > > > Start your free trial of AppDynamics Pro today!
> > > >
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > > > _______________________________________________
> > > > Csound-devel mailing list
> > > > Csound-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > >
> > > Dr Victor Lazzarini
> > > Senior Lecturer
> > > Dept. of Music
> > > NUI Maynooth Ireland
> > > tel.: +353 1 708 3545
> > > Victor dot Lazzarini AT nuim dot ie
> > >
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > See everything from the browser to the database with AppDynamics
> > > Get end-to-end visibility with application monitoring from AppDynamics
> > > Isolate bottlenecks and diagnose root cause in seconds.
> > > Start your free trial of AppDynamics Pro today!
> > >
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Csound-devel mailing list
> > > Csound-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> >
> > --
> > Anders Genell 
> >
> >
> > ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >


-- 
Anders Genell 

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net