[alsa-devel] implement delay in ioplug alsa plugin
Hi,
I managed to write an ioplug plugin which dumps a raw PCM stream to a file (similar to the way the file or tee plugins do, but without a slave device).
However, instead of immediately writing all the samples to the file, I would like to add some delay so that the samples are written to the file in real time at the frequency of the sampling rate.
Thus if there is a single channel stream with 16bits being played at a sampling rate of 8kHz, each 1/8000sec exactly 16 bits should be written to the file.
The reason for this is that I have a DSP attached over SPI which needs exactly one audio sample per interval. In order to talk to the DSP there is a SPI device-file which my ioplugin would use to write the samples to.
What is the best way to implement such a delay ?
I'm pretty sure that just adding some usleep calls() won't work very well, since the write operations to the device file probably don't take the same amount of time every time. Maybe it would work with non-blocking writes to the device file and a high precision timer ?
cheers, Stefan
At Wed, 19 Aug 2009 12:29:59 +0200, Stefan Schoenleitner wrote:
Hi,
I managed to write an ioplug plugin which dumps a raw PCM stream to a file (similar to the way the file or tee plugins do, but without a slave device).
However, instead of immediately writing all the samples to the file, I would like to add some delay so that the samples are written to the file in real time at the frequency of the sampling rate.
Thus if there is a single channel stream with 16bits being played at a sampling rate of 8kHz, each 1/8000sec exactly 16 bits should be written to the file.
The reason for this is that I have a DSP attached over SPI which needs exactly one audio sample per interval. In order to talk to the DSP there is a SPI device-file which my ioplugin would use to write the samples to.
What is the best way to implement such a delay ?
I'm pretty sure that just adding some usleep calls() won't work very well, since the write operations to the device file probably don't take the same amount of time every time. Maybe it would work with non-blocking writes to the device file and a high precision timer ?
hrtimer would be the most accurate method, I guess.
Takashi
participants (2)
-
Stefan Schoenleitner -
Takashi Iwai