[replying to pd-list]
Hi Simon
On Wed, 2016-10-12 at 09:30 +0200, Simon Iten wrote:
it would very much surprise me, if pd could do that in a generic way on all platforms. even daws or live struggle to do this *right* on different systems.
I'm not sure it's totally impossible. With jack, the latency is dependent on jackd's settings and I don't whether Pd has a change to know those. With ALSA, everything you need to know to calculate the latency Pd already knows.
why don't you patch a little tester app that sends some generated sounds, preferably with very clear attack, out and record this back in. that way you can measure the (roundtrip) latency of the whole system.
Of course, that is a way. "Knowing" the latency instead of "measuring" it would be so nice, though.
with a click track and a good musician that plays with it (that you record) you should be able to align generated sounds and live recorded material. this is how we do it in the studio if necessary :) but it is far from an automated process...
To make things at least a bit more feasible, I make the measured or calculated latency a configuration parameter, so that when you fire Pd up the next time with the same setup, the patch remembers the latency.
Roman
Am Sonntag, 9. Oktober 2016 schrieb Roman Haefeli :
Hi all,
I'm currently investigating audio latency compensation in Pd. The goal is for recorded audio to align well with generated sounds timing- wise. I'm wondering now what methods people already have employed in order to achieve that goal.
So far, I was able to find the formulas to calculate the correct latency when using ALSA and JACK audio back-ends as long as the paramaters 'Delay(msec)' and 'Block size' for ALSA, respectively 'Frames/period' and 'Periods/buffer' for JACK are known. Currently, this approach works, but requires me to tell the latency compensation calculator what driver I'm using and what the current settings are. Also, it yet only works on Linux, but not with any other drivers like CoreAudio, ASIO, etc.
How can I achieve correct latency compensation reliably on any platform? Is there some more generic way?
I'm also looking at IEM's mediasettings library, hoping it would deliver the required information to calculate latency. The README.txt says 'get/set Audio and MIDI settings within Pd', but I wasn't able to find a way to _get_ current settings other than 'advance 100', which probably refers to 'Delay(msec)' set to '100'. But still, if it would give all Pd audio settings, how would it know about current jackd settings?
Roman
On 19 Oct 2016, at 10:20, Roman Haefeli reduzent@gmail.com wrote:
[replying to pd-list]
Hi Simon
On Wed, 2016-10-12 at 09:30 +0200, Simon Iten wrote:
it would very much surprise me, if pd could do that in a generic way on all platforms. even daws or live struggle to do this *right* on different systems.
I'm not sure it's totally impossible. With jack, the latency is dependent on jackd's settings and I don't whether Pd has a change to know those. With ALSA, everything you need to know to calculate the latency Pd already knows.
but there is also an ADC and DAC latency, is jack or alsa aware of those as well? i believe typical adc/dac conversion can take up to 1.5ms…
why don't you patch a little tester app that sends some generated sounds, preferably with very clear attack, out and record this back in. that way you can measure the (roundtrip) latency of the whole system.
Of course, that is a way. "Knowing" the latency instead of "measuring" it would be so nice, though.
of course knowing is better than measuring :)
i think it is easy enough to measure roundtrip latency, it is harder to measure just “output” latency.
with a click track and a good musician that plays with it (that you record) you should be able to align generated sounds and live recorded material. this is how we do it in the studio if necessary :) but it is far from an automated process...
To make things at least a bit more feasible, I make the measured or calculated latency a configuration parameter, so that when you fire Pd up the next time with the same setup, the patch remembers the latency.
that sounds reasonable.
Roman
Am Sonntag, 9. Oktober 2016 schrieb Roman Haefeli :
Hi all,
I'm currently investigating audio latency compensation in Pd. The goal is for recorded audio to align well with generated sounds timing- wise. I'm wondering now what methods people already have employed in order to achieve that goal.
So far, I was able to find the formulas to calculate the correct latency when using ALSA and JACK audio back-ends as long as the paramaters 'Delay(msec)' and 'Block size' for ALSA, respectively 'Frames/period' and 'Periods/buffer' for JACK are known. Currently, this approach works, but requires me to tell the latency compensation calculator what driver I'm using and what the current settings are. Also, it yet only works on Linux, but not with any other drivers like CoreAudio, ASIO, etc.
How can I achieve correct latency compensation reliably on any platform? Is there some more generic way?
I'm also looking at IEM's mediasettings library, hoping it would deliver the required information to calculate latency. The README.txt says 'get/set Audio and MIDI settings within Pd', but I wasn't able to find a way to _get_ current settings other than 'advance 100', which probably refers to 'Delay(msec)' set to '100'. But still, if it would give all Pd audio settings, how would it know about current jackd settings?
Roman
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
This has been on my mind a long time - Pd really should provide a way to query the audio devices to whatever accuracy the underling system is capable of giving it.
I believe portaudio already does this - Pd can just piggyback on that and/or follow the portaudio model for whatever specialized I/O APIs it talks to.
cheers Miller
On Wed, Oct 19, 2016 at 01:42:25PM +0200, Simon Iten wrote:
On 19 Oct 2016, at 10:20, Roman Haefeli reduzent@gmail.com wrote:
[replying to pd-list]
Hi Simon
On Wed, 2016-10-12 at 09:30 +0200, Simon Iten wrote:
it would very much surprise me, if pd could do that in a generic way on all platforms. even daws or live struggle to do this *right* on different systems.
I'm not sure it's totally impossible. With jack, the latency is dependent on jackd's settings and I don't whether Pd has a change to know those. With ALSA, everything you need to know to calculate the latency Pd already knows.
but there is also an ADC and DAC latency, is jack or alsa aware of those as well? i believe typical adc/dac conversion can take up to 1.5ms…
why don't you patch a little tester app that sends some generated sounds, preferably with very clear attack, out and record this back in. that way you can measure the (roundtrip) latency of the whole system.
Of course, that is a way. "Knowing" the latency instead of "measuring" it would be so nice, though.
of course knowing is better than measuring :)
i think it is easy enough to measure roundtrip latency, it is harder to measure just “output” latency.
with a click track and a good musician that plays with it (that you record) you should be able to align generated sounds and live recorded material. this is how we do it in the studio if necessary :) but it is far from an automated process...
To make things at least a bit more feasible, I make the measured or calculated latency a configuration parameter, so that when you fire Pd up the next time with the same setup, the patch remembers the latency.
that sounds reasonable.
Roman
Am Sonntag, 9. Oktober 2016 schrieb Roman Haefeli :
Hi all,
I'm currently investigating audio latency compensation in Pd. The goal is for recorded audio to align well with generated sounds timing- wise. I'm wondering now what methods people already have employed in order to achieve that goal.
So far, I was able to find the formulas to calculate the correct latency when using ALSA and JACK audio back-ends as long as the paramaters 'Delay(msec)' and 'Block size' for ALSA, respectively 'Frames/period' and 'Periods/buffer' for JACK are known. Currently, this approach works, but requires me to tell the latency compensation calculator what driver I'm using and what the current settings are. Also, it yet only works on Linux, but not with any other drivers like CoreAudio, ASIO, etc.
How can I achieve correct latency compensation reliably on any platform? Is there some more generic way?
I'm also looking at IEM's mediasettings library, hoping it would deliver the required information to calculate latency. The README.txt says 'get/set Audio and MIDI settings within Pd', but I wasn't able to find a way to _get_ current settings other than 'advance 100', which probably refers to 'Delay(msec)' set to '100'. But still, if it would give all Pd audio settings, how would it know about current jackd settings?
Roman
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
why don't you patch a little tester app that sends some generated sounds, preferably with very clear attack, out and record this back in. that way you can measure the (roundtrip) latency of the whole system.
Of course, that is a way. "Knowing" the latency instead of "measuring" it would be so nice, though.
of course knowing is better than measuring :)
i think it is easy enough to measure roundtrip latency, it is harder to measure just “output” latency.
A good way to do this is to make this patch: [adc~]-[dac~]. Then, attach one channel of your scope to an old (cut-able) audio cable connected to the input and another channel to another old cable on the output. Then just send pulses or snap your fingers or whatever and look at the lag on the scope.
Whatever the latency is that results from DtoA will be nearly identical on the AtoD side because any pro audio device is going to have exactly the same filter on both ends. The sampling part of the conversion is nearly instantaneous. It depends on your audio backend how (when) the samples get pushed and pulled onto the CPU but that will be short too, especially if you set the latency value in Pd's to as low as it will go. So the RTT is the only thing you can measure, but it will probably be very, very close to 2x the output latency (unless you use Windows, in which case all bets are off!).
with a click track and a good musician that plays with it (that you record) you should be able to align generated sounds and live recorded material. this is how we do it in the studio if necessary :) but it is far from an automated process...
To make things at least a bit more feasible, I make the measured or calculated latency a configuration parameter, so that when you fire Pd up the next time with the same setup, the patch remembers the latency.
that sounds reasonable.
Roman
Am Sonntag, 9. Oktober 2016 schrieb Roman Haefeli :
Hi all,
I'm currently investigating audio latency compensation in Pd. The goal is for recorded audio to align well with generated sounds timing- wise. I'm wondering now what methods people already have employed in order to achieve that goal.
So far, I was able to find the formulas to calculate the correct latency when using ALSA and JACK audio back-ends as long as the paramaters 'Delay(msec)' and 'Block size' for ALSA, respectively 'Frames/period' and 'Periods/buffer' for JACK are known. Currently, this approach works, but requires me to tell the latency compensation calculator what driver I'm using and what the current settings are. Also, it yet only works on Linux, but not with any other drivers like CoreAudio, ASIO, etc.
How can I achieve correct latency compensation reliably on any platform? Is there some more generic way?
I'm also looking at IEM's mediasettings library, hoping it would deliver the required information to calculate latency. The README.txt says 'get/set Audio and MIDI settings within Pd', but I wasn't able to find a way to _get_ current settings other than 'advance 100', which probably refers to 'Delay(msec)' set to '100'. But still, if it would give all Pd audio settings, how would it know about current jackd settings?
Roman
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.atmailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi everybody, I've been thinking about latency compensation in the context of making a Pd external for Ableton Link. For the purposes of latency sensitive externals, it would be good to have functions in m_pd.h that allow externals to query the input and output latencies of the underlying platform. There's no general way to discover those values; the audio glue would have to implement them individually for each audio API. For some platforms we'd have to eyeball the latency figures, but that would still be useful.
The sample code that comes with the Link distribution may be instructive here: https://github.com/Ableton/link/tree/master/examples/linkaudio
Those samples use the latency provided by the audio API when available. Otherwise, e.g., for JACK, they seem to use audio buffer size as a proxy for latency.
Shall we consider adding latency-related functions to m_pd.h? Cheers, Peter
On Wed, Oct 19, 2016 at 10:20 AM, david medine dmedine@ucsd.edu wrote:
why don't you patch a little tester app that sends some generated sounds, preferably with very clear attack, out and record this back in. that way you can measure the (roundtrip) latency of the whole system.
Of course, that is a way. "Knowing" the latency instead of "measuring" it would be so nice, though.
of course knowing is better than measuring :)
i think it is easy enough to measure roundtrip latency, it is harder to measure just “output” latency.
A good way to do this is to make this patch: [adc~]-[dac~]. Then, attach one channel of your scope to an old (cut-able) audio cable connected to the input and another channel to another old cable on the output. Then just send pulses or snap your fingers or whatever and look at the lag on the scope.
Whatever the latency is that results from DtoA will be nearly identical on the AtoD side because any pro audio device is going to have exactly the same filter on both ends. The sampling part of the conversion is nearly instantaneous. It depends on your audio backend how (when) the samples get pushed and pulled onto the CPU but that will be short too, especially if you set the latency value in Pd's to as low as it will go. So the RTT is the only thing you can measure, but it will probably be very, very close to 2x the output latency (unless you use Windows, in which case all bets are off!).
with a click track and a good musician that plays with it (that you record) you should be able to align generated sounds and live recorded material. this is how we do it in the studio if necessary :) but it is far from an automated process...
To make things at least a bit more feasible, I make the measured or calculated latency a configuration parameter, so that when you fire Pd up the next time with the same setup, the patch remembers the latency.
that sounds reasonable.
Roman
Am Sonntag, 9. Oktober 2016 schrieb Roman Haefeli :
Hi all,
I'm currently investigating audio latency compensation in Pd. The goal is for recorded audio to align well with generated sounds timing- wise. I'm wondering now what methods people already have employed in order to achieve that goal.
So far, I was able to find the formulas to calculate the correct latency when using ALSA and JACK audio back-ends as long as the paramaters 'Delay(msec)' and 'Block size' for ALSA, respectively 'Frames/period' and 'Periods/buffer' for JACK are known. Currently, this approach works, but requires me to tell the latency compensation calculator what driver I'm using and what the current settings are. Also, it yet only works on Linux, but not with any other drivers like CoreAudio, ASIO, etc.
How can I achieve correct latency compensation reliably on any platform? Is there some more generic way?
I'm also looking at IEM's mediasettings library, hoping it would deliver the required information to calculate latency. The README.txt says 'get/set Audio and MIDI settings within Pd', but I wasn't able to find a way to _get_ current settings other than 'advance 100', which probably refers to 'Delay(msec)' set to '100'. But still, if it would give all Pd audio settings, how would it know about current jackd settings?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata. info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
-
david medine -
Miller Puckette -
Peter Brinkmann -
Roman Haefeli -
Simon Iten