[alsa-devel] Clock Drift between hardware sound card and snd_aloop
Hi all,
I have successfully built a sound capture card that runs at a given rate off its own clock. I receive the stream and do some post-processing on it, and I want to present this modified data to the user as a capture pcm.
I initially thought that snd_aloop would be the best idea, as I can pipe my post-processed data directly into it. However, the driver is apparently calculating exact timing of what "should" be the rate based off of CPU ticks/jiffies and the requested period/sample rate/etc in the requested output stream.
In my actual hardware I see cycle slips. Underruns and overruns based off of minor adjustments to the card's rate.
Is snd_aloop the appropriate driver to be using? Or should I create a new card, similar to snd_aloop, which is more specifically interrupted (and associated pointer locations, etc. modified) from the hardware card as well?
It seems like I should be able to synchronize snd_aloop's timing with my hardware clock, but I haven't found anywhere in the API to achieve this.
How else can I avoid this clock drift?
Thanks, Rob
Rob Nertney wrote:
I have successfully built a sound capture card that runs at a given rate off its own clock. I receive the stream and do some post-processing on it, and I want to present this modified data to the user as a capture pcm.
Then you probably want to create an external filter plugin: http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_external_plugins.html
I initially thought that snd_aloop would be the best idea, as I can pipe my post-processed data directly into it. However, the driver is apparently calculating exact timing of what "should" be the rate based off of CPU ticks/jiffies and the requested period/sample rate/etc in the requested output stream.
Yes; the timing is not synchronized with any other sound card.
Regards, Clemens
participants (2)
-
Clemens Ladisch
-
Rob Nertney