On 2016-04-28 12:38, Mark Brown wrote:
On Wed, Apr 27, 2016 at 10:45:48PM +0200, Peter Rosin wrote:
I haven't looked really closely at the userspace side of this, but the big picture is that we're using a (closed source) library that in its documentation has an example where they open /dev/dsp like this and feeds the fd to the lib. We are simply replicating that in our code. I don't know if the library does anything OSSy with the fd, or if it would be equally happy with an ALSA fd.
If it's using OSS it's unlikely to work with ALSA, the two ABIs are completely different. You need to talk to your proprietary software vendor about updating their software. There are also some userspace utilities that try to do the remapping by wrapping things there but I can't remember the names off the top of my head, it's been a long time.
Ok, I managed to hook it up with ALSA instead but am now bitten by a completely different problem.
The code now does this (error checks elided, there are no errors reported in the real code which does check for errors):
snd_pcm_open(&pcm, "default", SND_PCM_STREAM_PLAYBACK, 0); snd_pcm_set_params(pcm, SND_PCM_FORMAT_S16_LE, SND_PCM_ACCESS_RW_INTERLEAVED, 2, 22050, 0, 1000000); while (!end) { /* code filling in stereo_buf elided */ snd_pcm_writei(pcm, stereo_buf, sample_count); } snd_pcm_drain(pcm); snd_pcm_close(pcm);
There is no rate control in this, the code relies on snd_pcm_writei to block if there is no room. This part appears to work as expected. sample_count is not constant, but it is mostly 4096 and never bigger than that.
The problem is in the drain/close part. If I leave out snd_pcm_drain I naturally lose the tail of the output, but if I have it I get what I guess is a repeat of the content in some circular buffer. I.e. the very last part of the played sound is played twice(ice).
If I instead write the generated samples to a file and play them with aplay, all is fine, so I appear to be misunderstanding the alsa api?
Anything obviously wrong in the above code?
Cheers, Peter