[alsa-devel] Timestamps using I/O Plugin
I was excited when I found that it was possible to write user space drivers for ALSA, but I can't get my head around how timestamping works when using a I/O plugin instance.
I better start explaining what we want to do. Basically we just want to transfer raw audio between the HOST running ALSA and one or more small(tiny) network connected MCUs with audio codecs. We need to synchronize the different network sources with the local HW sources (on the ALSA HOST).
Starting looking into how timestamps is handled by ALSA I could not find how it was possible to set the timestamp, there seems to be some differences compared to using a normal kernel driver!? If I understand it correctly timestamp can be obtained by calling snd_pcm_status() but the ioplugs implementation of the .status() newer fills in the ->tstamp only the ->trigger_tstamp, so how can I set the timestamp of the data my plugin delivers to ALSA? Additionally snd_pcm_htimestamp() only seams to return the current monotonic clock at the point the function was called for an ioplug instance!?
I saw that there are plugins for pulseaudio and jack doing what we whant to achieve but because of the footprint of the MCU we can't use PA/Jack on these MCU:s. But how have they solved this issue or isn't it an issue for their usecase? /JohanHellman
After spending more time investigating how I would set monotonic timestamps from a new I/O plugin so that the app using ALSA lib could synchronize different audio streams I cant find that its possible!?
Can someone please confirm that it is not possible to set monotonic timestamps using the I/O plugin SDK!?
The new plugin would know the relationship between audio streams timestamp information and the systems monotonic clock. If it was possible to override the snd_pcm_htimestamp() then the timestamp could be fetched from the I/O plugin, and snd_pcm_status()->snd_pcm_ioplug_status() could call that overridden function to fill in tstamp into the status object. If not implemented in the I/O plugin call snd_pcm_generic_real_htimestamp() as today. Would this be an acceptable way forward?
/JohanHellman ________________________________________ From: alsa-devel-bounces@alsa-project.org [alsa-devel-bounces@alsa-project.org] On Behalf Of Johan Hellman [johanhn@axis.com] Sent: Friday, May 31, 2013 11:22 AM To: alsa-devel@alsa-project.org Subject: [alsa-devel] Timestamps using I/O Plugin
I was excited when I found that it was possible to write user space drivers for ALSA, but I can't get my head around how timestamping works when using a I/O plugin instance.
I better start explaining what we want to do. Basically we just want to transfer raw audio between the HOST running ALSA and one or more small(tiny) network connected MCUs with audio codecs. We need to synchronize the different network sources with the local HW sources (on the ALSA HOST).
Starting looking into how timestamps is handled by ALSA I could not find how it was possible to set the timestamp, there seems to be some differences compared to using a normal kernel driver!? If I understand it correctly timestamp can be obtained by calling snd_pcm_status() but the ioplugs implementation of the .status() newer fills in the ->tstamp only the ->trigger_tstamp, so how can I set the timestamp of the data my plugin delivers to ALSA? Additionally snd_pcm_htimestamp() only seams to return the current monotonic clock at the point the function was called for an ioplug instance!?
I saw that there are plugins for pulseaudio and jack doing what we whant to achieve but because of the footprint of the MCU we can't use PA/Jack on these MCU:s. But how have they solved this issue or isn't it an issue for their usecase? /JohanHellman
_______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Thu, 6 Jun 2013 09:01:12 +0200, Johan Hellman wrote:
After spending more time investigating how I would set monotonic timestamps from a new I/O plugin so that the app using ALSA lib could synchronize different audio streams I cant find that its possible!?
Can someone please confirm that it is not possible to set monotonic timestamps using the I/O plugin SDK!?
AFAIK, there is nothing special in ioplug layer but it's a matter of ioplug plugin instance. If the plugin sets SND_PCM_IOPLUG_FLAG_MONOTONIC bit to ioplug->flags, the ioplug layer uses the monotonic timestamp (via clock_gettime()) instead of gettimeofday(). So far, no plugins in alsa-plugins provide SND_PCM_IOPLUG_FLAG_MONOTONIC yet, though.
Takashi
The new plugin would know the relationship between audio streams timestamp information and the systems monotonic clock. If it was possible to override the snd_pcm_htimestamp() then the timestamp could be fetched from the I/O plugin, and snd_pcm_status()->snd_pcm_ioplug_status() could call that overridden function to fill in tstamp into the status object. If not implemented in the I/O plugin call snd_pcm_generic_real_htimestamp() as today. Would this be an acceptable way forward?
/JohanHellman ________________________________________ From: alsa-devel-bounces@alsa-project.org [alsa-devel-bounces@alsa-project.org] On Behalf Of Johan Hellman [johanhn@axis.com] Sent: Friday, May 31, 2013 11:22 AM To: alsa-devel@alsa-project.org Subject: [alsa-devel] Timestamps using I/O Plugin
I was excited when I found that it was possible to write user space drivers for ALSA, but I can't get my head around how timestamping works when using a I/O plugin instance.
I better start explaining what we want to do. Basically we just want to transfer raw audio between the HOST running ALSA and one or more small(tiny) network connected MCUs with audio codecs. We need to synchronize the different network sources with the local HW sources (on the ALSA HOST).
Starting looking into how timestamps is handled by ALSA I could not find how it was possible to set the timestamp, there seems to be some differences compared to using a normal kernel driver!? If I understand it correctly timestamp can be obtained by calling snd_pcm_status() but the ioplugs implementation of the .status() newer fills in the ->tstamp only the ->trigger_tstamp, so how can I set the timestamp of the data my plugin delivers to ALSA? Additionally snd_pcm_htimestamp() only seams to return the current monotonic clock at the point the function was called for an ioplug instance!?
I saw that there are plugins for pulseaudio and jack doing what we whant to achieve but because of the footprint of the MCU we can't use PA/Jack on these MCU:s. But how have they solved this issue or isn't it an issue for their usecase? /JohanHellman
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Thu, 6 Jun 2013 09:01:12 +0200, Johan Hellman wrote:
After spending more time investigating how I would set monotonic timestamps from a new I/O plugin so that the app using ALSA lib could synchronize different audio streams I cant find that its possible!?
Can someone please confirm that it is not possible to set monotonic timestamps using the I/O plugin SDK!?
AFAIK, there is nothing special in ioplug layer but it's a matter of ioplug plugin instance. If the plugin sets SND_PCM_IOPLUG_FLAG_MONOTONIC bit to ioplug->flags, the ioplug layer uses the monotonic timestamp (via clock_gettime()) instead of gettimeofday(). So far, no plugins in alsa-plugins provide SND_PCM_IOPLUG_FLAG_MONOTONIC yet, though.
Takashi
Thanks for your reply, by enabling SND_PCM_IOPLUG_FLAG_MONOTONIC the ioplug would return a monotonic timestamp if requested by calling snd_pcm_htimestamp() but it would be the current timestamp i.e. change every time you call ..htimestamp() and not be related to the last buffer update or anything(within ALSA) actually??. And there would be no timestamp information in the snd_pcm_status_t returned by snd_pcm_status() or am i missing something?
What i found in the implementation for the ioplug layer(snd_pcm_ioplug_status) was that the status struct was memset to 0 but the tstamp is not set, so 0 is returned as a monotonic timestamp.
Would a change similar to what i wrote in my previus post regarding adding the possibility for the plugin to override ..htimestamp() and the ioplug layer to update tstamp in the status struct using that function (if available)?
/JohanHellman
If it was possible to override the snd_pcm_htimestamp() then the timestamp could be fetched from the I/O plugin, and snd_pcm_status()->snd_pcm_ioplug_status() could call that overridden function to fill in tstamp into the status object. If not implemented in the I/O plugin call >snd_pcm_generic_real_htimestamp() as today. Would this be an acceptable way forward?
Would this be an acceptable way to let a ioplugin support setting timestamps related to the monotonic system clock? The ioplugin implementation would handle the relationship between the systems monotonic clock and the audio streams clock source, making a network source transparent to alsa but the applications could synchronize different streams.
/JohanHellman
On Thu, 2013-06-06 at 14:54 +0200, Johan Hellman wrote:
At Thu, 6 Jun 2013 09:01:12 +0200, Johan Hellman wrote:
After spending more time investigating how I would set monotonic timestamps from a new I/O plugin so that the app using ALSA lib could synchronize different audio streams I cant find that its possible!?
Can someone please confirm that it is not possible to set monotonic timestamps using the I/O plugin SDK!?
AFAIK, there is nothing special in ioplug layer but it's a matter of ioplug plugin instance. If the plugin sets SND_PCM_IOPLUG_FLAG_MONOTONIC bit to ioplug->flags, the ioplug layer uses the monotonic timestamp (via clock_gettime()) instead of gettimeofday(). So far, no plugins in alsa-plugins provide SND_PCM_IOPLUG_FLAG_MONOTONIC yet, though.
Takashi
Thanks for your reply, by enabling SND_PCM_IOPLUG_FLAG_MONOTONIC the ioplug would return a monotonic timestamp if requested by calling snd_pcm_htimestamp() but it would be the current timestamp i.e. change every time you call ..htimestamp() and not be related to the last buffer update or anything(within ALSA) actually??. And there would be no timestamp information in the snd_pcm_status_t returned by snd_pcm_status() or am i missing something?
What i found in the implementation for the ioplug layer(snd_pcm_ioplug_status) was that the status struct was memset to 0 but the tstamp is not set, so 0 is returned as a monotonic timestamp.
Would a change similar to what i wrote in my previus post regarding adding the possibility for the plugin to override ..htimestamp() and the ioplug layer to update tstamp in the status struct using that function (if available)?
/JohanHellman
snd_pcm_ioplug_status() is missing a call to gettimestamp(&status->tstamp, pcm->monotonic); compared to other overridden _status functions (dshare/dmix etc..).
With gettimestamp() added to the ioplug, calls to snd_pcm_status() would fill in a timestamp and SNDRV_PCM_TSTAMP_TYPE_MONOTONIC would determine if the timestamp returned would be monotonic or not.
This would not fix my problem. If a kernel drivers has SNDRV_PCM_TSTAMP_ENABLE set then ALSA lets the driver return the timestamp, a ioplugin does not have this possibility.
Any comments or suggestions on how to proceed?
/JohanHellman
participants (2)
-
Johan Hellman -
Takashi Iwai