Possible problem with snd_pcm_oss_sync()

Possible problem with snd_pcm_oss_sync()

[Timur Tabi]

-------- 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
Linux kernel developer at Freescale

Re: Possible problem with snd_pcm_oss_sync()

[Timur Tabi]

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
Linux kernel developer at Freescale

Re: Possible problem with snd_pcm_oss_sync()

[Clemens Ladisch]

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:
> 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);",

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

Re: Possible problem with snd_pcm_oss_sync()

[Takashi Iwai]

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:
> 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);",

This looks weird.  The mixer ioctl is independent from the PCM,
basically.

> #2) Stopped audio stream output after doing following:
> 1. Opening /dev/dsp
> 2. 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
> 

Re: Possible problem with snd_pcm_oss_sync()

[Timur Tabi]

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.

-- 
Timur Tabi
Linux kernel developer at Freescale