[alsa-devel] Driver recovers from underrun in plain ALSA mode, but not in OSS emulation
I'm stress-testing my sound driver using mplayer to see how it handles underrun during jumps in CPU loads. That is, I start playing a movie, and then I cause the CPU to jump to 100%, and then I drop the CPU back to normal. During the times when the CPU is at 100%, I get underruns and other problems. That's normal.
When I tell mplayer to use the ALSA API, my driver recovers nicely from an underrun situation when the CPU load drops back to normal. However, if I tell mplayer to use the OSS API (i.e. ALSA's OSS emulation), it does not recover from an underrun situation. The audio and video playback remains distorted. I need to tell mplayer to pause and resume to get it to recover.
Is this normal for ALSA drivers? Before I try to debug this problem the hard way, I want to know if this could be the result of a common programming mistake in my driver or something like similar.
(FYI, the source code for my driver is in sound/soc/fsl/)
At Fri, 29 Feb 2008 17:56:43 -0600, Timur Tabi wrote:
I'm stress-testing my sound driver using mplayer to see how it handles underrun during jumps in CPU loads. That is, I start playing a movie, and then I cause the CPU to jump to 100%, and then I drop the CPU back to normal. During the times when the CPU is at 100%, I get underruns and other problems. That's normal.
When I tell mplayer to use the ALSA API, my driver recovers nicely from an underrun situation when the CPU load drops back to normal. However, if I tell mplayer to use the OSS API (i.e. ALSA's OSS emulation), it does not recover from an underrun situation. The audio and video playback remains distorted. I need to tell mplayer to pause and resume to get it to recover.
Is this normal for ALSA drivers? Before I try to debug this problem the hard way, I want to know if this could be the result of a common programming mistake in my driver or something like similar.
No, it's not normal.
The question is whether OSS emulation really notices the underrun. More likely, it's caused by the difference of parameters.
Takashi
At Tue, 04 Mar 2008 09:20:36 -0600, Timur Tabi wrote:
Takashi Iwai wrote:
The question is whether OSS emulation really notices the underrun. More likely, it's caused by the difference of parameters.
Can you explain, please? Which parameters could be different?
In many cases, some of hw_params or sw_params values are different even on the same app when different APIs are used. You can check pcm*/sub*/* proc files to compare. Usually it's because of different constraints, e.g. OSS API requires power-of-two bytes alignment for buffer controls.
Takashi
participants (2)
-
Takashi Iwai -
Timur Tabi