[alsa-devel] Possible problem with snd_pcm_oss_sync()
-------- Original Message -------- Subject: RE: Regarding MPC8610 BSP question and issue Date: Tue, 20 May 2008 08:55:46 -0700 From: Hayasaka Manabu manabu.hayasaka@freescale.com To: Hayasaka Manabu manabu.hayasaka@freescale.com, Johnson Kelly Kelly.Johnson@freescale.com CC: sun york yorksun@freescale.com, Namiki Ayumi namiki@freescale.com, Beck Glenn Glenn.Beck@freescale.com, Cox Kevin K.Cox@freescale.com, Hamano Masahiro M.Hamano@freescale.com, Tabi Timur timur@freescale.com References: E03EE6E38549E949AE8138F60493E1E801C49A0C@zja67exm20.fsl.freescale.net 4807899D.3000901@freescale.com E03EE6E38549E949AE8138F60493E1E801DA1B11@zja67exm20.fsl.freescale.net 48110FCF.7070302@freescale.com BD243C8D8F65694A966948E9D51F9815C29409@zja67exm21.fsl.freescale.net 48189540.9060309@freescale.com BD243C8D8F65694A966948E9D51F9815C29422@zja67exm21.fsl.freescale.net E03EE6E38549E949AE8138F60493E1E801DA25D9@zja67exm20.fsl.freescale.net 4821CA02.2020504@freescale.com E03EE6E38549E949AE8138F60493E1E801FA11C8@zja67exm20.fsl.freescale.net 4829C444.7010206@freescale.com E03EE6E38549E949AE8138F60493E1E801FA13D2@zja67exm20.fsl.freescale.net 482B1D10.7090402@freescale.com 482B2699.8020409@freescale.com
I'm working with a customer that has discovered a possible problem with OSS emulation. Unfortunately, I don't have a lot of experience with OSS, so I need help understanding whether the customer's observations point to a real problem or not.
The customer is using an old application called "bplay" to test OSS audio support on our hardware. The application works fine on x86, but fails on our PowerPC board. It could be an endian issue, but I doubt it.
Here is the forwarded email (slightly edited). Can someone familiar with the OSS "sync" functionality comment?
---------------
They reported that it seemed some ioctl commands in the OSS emulation did not work correctly.
The tested procedure of the ioctl commands are as following,
#1) Stopped audio stream output after doing followings: 1. Opening /dev/mixer 2. Getting a channel value (0x00000001) that is used for "ioctl(fd, SOUND_MIXER_READ_DEVMASK, &Sndsts);". 3. Write audio volume information by "ioctl(fd, SOUND_MIXER_WRITE_VOLUME, &Value);",
#2) Stopped audio stream output after doing following: 1. Opening /dev/dsp 2. Executing command "ioctl(fd, SNDCTL_DSP_SYNC, NULL);",
XXXX found that by commenting out the "sync_audio" function on the source code of "bplay" made "bplay" work. So XXXX suspects the implementation of the ioctl on the OSS emulation may have a problem.
Timur Tabi wrote:
I'm working with a customer that has discovered a possible problem with OSS emulation. Unfortunately, I don't have a lot of experience with OSS, so I need help understanding whether the customer's observations point to a real problem or not.
Update:
snd_pcm_oss_sync() displays this message:
sync: buffer_used
What does this mean? What does it mean to sync, and why would an OSS application call sync?
Timur Tabi wrote:
The customer is using an old application called "bplay" to test OSS audio support on our hardware. The application works fine on x86, but fails on our PowerPC board. It could be an endian issue, but I doubt it.
Is that a recent enough version of bplay, from Debian? Older ones didn't work on big-endian machines.
#1) Stopped audio stream output after doing followings:
- Opening /dev/mixer
- Getting a channel value (0x00000001) that is used for "ioctl(fd,
SOUND_MIXER_READ_DEVMASK, &Sndsts);". 3. Write audio volume information by "ioctl(fd, SOUND_MIXER_WRITE_VOLUME, &Value);",
I didn't find this in the bplay code.
If writing to a mixer control stops the audio stream, this may be a bug in the driver (whatever driver this is).
#2) Stopped audio stream output after doing following: 2. Executing command "ioctl(fd, SNDCTL_DSP_SYNC, NULL);",
This ioctl stops the output (after playing the remaining data in the buffer). The application can restart playing by writing more data.
XXXX found that by commenting out the "sync_audio" function on the source code of "bplay" made "bplay" work. So XXXX suspects the implementation of the ioctl on the OSS emulation may have a problem.
bplay calls the SYNC ioctl before setting the sample format, but this is not allowed: http://manuals.opensound.com/developer/callorder.html.
Removing that call to sync_audio() fixes the bug. :-)
snd_pcm_oss_sync() displays this message:
sync: buffer_used
What does this mean?
It means that the buffer contains some data which will be played before the device is stopped and the ioctl returns.
HTH Clemens
At Tue, 20 May 2008 11:03:42 -0500, Timur Tabi wrote:
-------- Original Message -------- Subject: RE: Regarding MPC8610 BSP question and issue Date: Tue, 20 May 2008 08:55:46 -0700 From: Hayasaka Manabu manabu.hayasaka@freescale.com To: Hayasaka Manabu manabu.hayasaka@freescale.com, Johnson Kelly Kelly.Johnson@freescale.com CC: sun york yorksun@freescale.com, Namiki Ayumi namiki@freescale.com, Beck Glenn Glenn.Beck@freescale.com, Cox Kevin K.Cox@freescale.com, Hamano Masahiro M.Hamano@freescale.com, Tabi Timur timur@freescale.com References: E03EE6E38549E949AE8138F60493E1E801C49A0C@zja67exm20.fsl.freescale.net 4807899D.3000901@freescale.com E03EE6E38549E949AE8138F60493E1E801DA1B11@zja67exm20.fsl.freescale.net 48110FCF.7070302@freescale.com BD243C8D8F65694A966948E9D51F9815C29409@zja67exm21.fsl.freescale.net 48189540.9060309@freescale.com BD243C8D8F65694A966948E9D51F9815C29422@zja67exm21.fsl.freescale.net E03EE6E38549E949AE8138F60493E1E801DA25D9@zja67exm20.fsl.freescale.net 4821CA02.2020504@freescale.com E03EE6E38549E949AE8138F60493E1E801FA11C8@zja67exm20.fsl.freescale.net 4829C444.7010206@freescale.com E03EE6E38549E949AE8138F60493E1E801FA13D2@zja67exm20.fsl.freescale.net 482B1D10.7090402@freescale.com 482B2699.8020409@freescale.com
I'm working with a customer that has discovered a possible problem with OSS emulation. Unfortunately, I don't have a lot of experience with OSS, so I need help understanding whether the customer's observations point to a real problem or not.
The customer is using an old application called "bplay" to test OSS audio support on our hardware. The application works fine on x86, but fails on our PowerPC board. It could be an endian issue, but I doubt it.
Here is the forwarded email (slightly edited). Can someone familiar with the OSS "sync" functionality comment?
They reported that it seemed some ioctl commands in the OSS emulation did not work correctly.
The tested procedure of the ioctl commands are as following,
#1) Stopped audio stream output after doing followings:
- Opening /dev/mixer
- Getting a channel value (0x00000001) that is used for "ioctl(fd,
SOUND_MIXER_READ_DEVMASK, &Sndsts);". 3. Write audio volume information by "ioctl(fd, SOUND_MIXER_WRITE_VOLUME, &Value);",
This looks weird. The mixer ioctl is independent from the PCM, basically.
#2) Stopped audio stream output after doing following:
- Opening /dev/dsp
- Executing command "ioctl(fd, SNDCTL_DSP_SYNC, NULL);",
The sync ioctl is to block the operation until all samples are played. But, it's a bit strange that the stream stops after this. It should be an underrun instead (and OSS recovers by itself).
Takashi
XXXX found that by commenting out the "sync_audio" function on the source code of "bplay" made "bplay" work. So XXXX suspects the implementation of the ioctl on the OSS emulation may have a problem.
-- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Takashi Iwai wrote:
The sync ioctl is to block the operation until all samples are played. But, it's a bit strange that the stream stops after this. It should be an underrun instead (and OSS recovers by itself).
I figured it out. When the application starts, my driver gets a call to the _hw_params and _prepare functions. When the app calls SNDCTL_DSP_SYNC, those two functions get called again. At that point, the DMA controller gets re-programmed. For some reason, it doesn't like that. The DMA never actually starts.
I moved some of the DMA programming code to my _open function (where it belongs, anyway), and now bplay works.
Well, almost. After about a second into playback, it skips a little bit. And then about 4-5 seconds later, bplay calls SNDCTL_DSP_SYNC, and that causes playback to pause for about a second.
I need to figure out why bplay is calling sync, and why the audio skips in the beginning.
participants (3)
-
Clemens Ladisch -
Takashi Iwai -
Timur Tabi