[alsa-devel] Any OSS changes from kernel 2.6.21 to 2.6.23? Something broke.
I have a customer who says that mplayer (using OSS) does not work when he tries a kernel based on 2.6.23-rc4, but it works when he uses a kernel based on 2.6.21. Everything else is the same (including the version of alsa-lib), so I presume something broke in the OSS emulation in the kernel. Unfortunately, our git repositories for these trees are not compatible, so I can't use git-bisect to narrow the problem down.
Is it possible to back-level the ALSA support in the kernel itself? Can I just download ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.XX.tar.bz2 and follow the instructions in the INSTALL file?
If you update the kernel, are you supposed to use the latest alsa-lib as well? For a given kernel, how do I know what the right version of alsa-lib is?
Timur Tabi wrote:
I have a customer who says that mplayer (using OSS) does not work when he tries a kernel based on 2.6.23-rc4, but it works when he uses a kernel based on 2.6.21. Everything else is the same (including the version of alsa-lib), so I presume something broke in the OSS emulation in the kernel.
It could also be a change in the driver.
And it would be nice to know what "does not work" actually means.
Is it possible to back-level the ALSA support in the kernel itself?
The alsa-kernel tree is only compatible with the current development kernel.
The alsa-driver package works with older kernels, but must be compiled seperately.
Can I just download ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.XX.tar.bz2 and follow the instructions in the INSTALL file?
Yes.
If you update the kernel, are you supposed to use the latest alsa-lib as well?
No; the kernel and lib versions are more or less independent.
HTH Clemens
Clemens Ladisch wrote:
Timur Tabi wrote:
I have a customer who says that mplayer (using OSS) does not work when he tries a kernel based on 2.6.23-rc4, but it works when he uses a kernel based on 2.6.21. Everything else is the same (including the version of alsa-lib), so I presume something broke in the OSS emulation in the kernel.
It could also be a change in the driver.
And it would be nice to know what "does not work" actually means.
I didn't want to get into a length description of the problem without first seeing if there were any obvious changes. There are still a few things I can debug.
The problem I'm seeing is that when using mplayer to play a video file through the OSS interface, at some point in the movie, the driver will stop telling ALSA that has finished playing a period. It's almost as if ALSA is throttling the driver incorrectly.
If I tell mplayer to just play the file through OSS, the problem occurs almost immediately. If I tell mplayer to convert the sample rate from 44100 to 48000 (my driver understands 48000 but not 44100), the problem doesn't always occur, but when it does (about every other time I play the file), it starts to happen about 5 seconds into the file.
Timur Tabi wrote:
Clemens Ladisch wrote:
Timur Tabi wrote:
I have a customer who says that mplayer (using OSS) does not work when he tries a kernel based on 2.6.23-rc4, but it works when he uses a kernel based on 2.6.21. Everything else is the same (including the version of alsa-lib), so I presume something broke in the OSS emulation in the kernel.
It could also be a change in the driver.
And it would be nice to know what "does not work" actually means.
I didn't want to get into a length description of the problem without first seeing if there were any obvious changes. There are still a few things I can debug.
The problem I'm seeing is that when using mplayer to play a video file through the OSS interface, at some point in the movie, the driver will stop telling ALSA that has finished playing a period. It's almost as if ALSA is throttling the driver incorrectly.
If I tell mplayer to just play the file through OSS, the problem occurs almost immediately. If I tell mplayer to convert the sample rate from 44100 to 48000 (my driver understands 48000 but not 44100), the problem doesn't always occur, but when it does (about every other time I play the file), it starts to happen about 5 seconds into the file.
Why are you using OSS. mplayer supports ALSA direct.
James Courtier-Dutton wrote:
Why are you using OSS. mplayer supports ALSA direct.
I'm not -- our customer is. They're using mplayer to validate the OSS support for their legacy OSS application.
At Fri, 02 Nov 2007 10:36:54 -0500, Timur Tabi wrote:
I have a customer who says that mplayer (using OSS) does not work when he tries a kernel based on 2.6.23-rc4, but it works when he uses a kernel based on 2.6.21. Everything else is the same (including the version of alsa-lib), so I presume something broke in the OSS emulation in the kernel. Unfortunately, our git repositories for these trees are not compatible, so I can't use git-bisect to narrow the problem down.
There is no relevant change regarding OSS-emulation code in kernel between 2.6.21 and 2.6.23.
Takashi
Takashi Iwai wrote:
There is no relevant change regarding OSS-emulation code in kernel between 2.6.21 and 2.6.23.
It turns out that ALSA (when using mplayer to play a divx video file via OSS emulation) is rapidly sending back-to-back SNDRV_PCM_TRIGGER_STOP and SNDRV_PCM_TRIGGER_START commands. Why would it do that?
Timur Tabi wrote:
It turns out that ALSA (when using mplayer to play a divx video file via OSS emulation) is rapidly sending back-to-back SNDRV_PCM_TRIGGER_STOP and SNDRV_PCM_TRIGGER_START commands. Why would it do that?
To recover from underruns.
There shouldn't be any difference, but maybe the buffer size of the driver has changed. Could you show the output of mplayer with the "-v" option for both kernels?
Regards, Clemens
Clemens Ladisch wrote:
Timur Tabi wrote:
It turns out that ALSA (when using mplayer to play a divx video file via OSS emulation) is rapidly sending back-to-back SNDRV_PCM_TRIGGER_STOP and SNDRV_PCM_TRIGGER_START commands. Why would it do that?
To recover from underruns.
I typically get the STOP command just milliseconds before the period ends. ALSA is pretty impatient! How does ALSA (in OSS emulation mode) know that an underrun has occurred?
There shouldn't be any difference, but maybe the buffer size of the driver has changed. Could you show the output of mplayer with the "-v" option for both kernels?
Unfortunately, I can't seem to get the original kernel to work now, so it's broken on all kernels. Anywhere, here's the mplayer output on out 2.6.23-based kernel:
Linux MPC8610HPCD 2.6.23-6 #20 Thu Nov 8 10:02:21 CST 2007 ppc GNU/Linux:
# mplayer -v -ao oss Cars480_1[1].5M.divx MPlayer 1.0rc2-3.3.5 (C) 2000-2007 MPlayer Team AltiVec found CPU: PowerPC get_path('codecs.conf') -> '/root/.mplayer/codecs.conf' Reading /root/.mplayer/codecs.conf: Can't open '/root/.mplayer/codecs.conf': No such file or directory Reading /usr/local/etc/mplayer/codecs.conf: Can't open '/usr/local/etc/mplayer/codecs.conf': No such file or directory Using built-in default codecs.conf. Configuration: CommandLine: '-v' '-ao' 'oss' 'Cars480_1[1].5M.divx' get_path('font/font.desc') -> '/root/.mplayer/font/font.desc' font: can't open file: /root/.mplayer/font/font.desc font: can't open file: /usr/local/share/mplayer/font/font.desc Using Unoptimized OnScreenDisplay Using nanosleep() timing get_path('input.conf') -> '/root/.mplayer/input.conf' Can't open input config file /root/.mplayer/input.conf: No such file or directory Can't open input config file /usr/local/etc/mplayer/input.conf: No such file or directory Falling back on default (hardcoded) input config get_path('Cars480_1[1].5M.divx.conf') -> '/root/.mplayer/Cars480_1[1].5M.divx.conf'
Playing Cars480_1[1].5M.divx. get_path('sub/') -> '/root/.mplayer/sub/' [file] File size is 11142774 bytes STREAM: [file] Cars480_1[1].5M.divx STREAM: Description: File STREAM: Author: Albeu STREAM: Comment: based on the code from ??? (probably Arpi) LAVF_check: avi format AVI file format detected. list_end=0x264 ======= AVI Header ======= us/frame: 41710 (fps=23.975) max bytes/sec: 0 padding: 0 MainAVIHeader.dwFlags: (272) HAS_INDEX IS_INTERLEAVED frames total: 1319 initial: 0 streams: 2 Suggested BufferSize: 0 Size: 848 x 352 ========================== list_end=0xDC ==> Found video stream: 0 [aviheader] Video stream found, -vid 0 ====== STREAM Header ===== Type: sdiv FCC: XVID (58564944) Flags: 0 Priority: 0 Language: 0 InitialFrames: 0 Rate: 23975/1000 = 23.975 Start: 0 Len: 1319 Suggested BufferSize: 93750 Quality 0 Sample size: 0 ========================== Found 'bih', 40 bytes of 40 ======= VIDEO Format ====== biSize 40 biWidth 848 biHeight 352 biPlanes 1 biBitCount 24 biCompression 808802372='05XD' biSizeImage 895488 =========================== Regenerating keyframe table for MPEG-4 video. list_end=0x15C ==> Found audio stream: 1 [aviheader] Audio stream found, -aid 1 ====== STREAM Header ===== Type: sdua FCC: (0) Flags: 0 Priority: 0 Language: 0 InitialFrames: 1 Rate: 16000/1 = 16000.000 Start: 0 Len: 879574 Suggested BufferSize: 8000 Quality -1 Sample size: 1 ========================== Found 'wf', 30 bytes of 18 ======= WAVE Format ======= Format Tag: 85 (0x55) Channels: 2 Samplerate: 44100 avg byte/sec: 16000 Block align: 1 bits/sample: 0 cbSize: 12 mp3.wID=256 mp3.fdwFlags=0x0 mp3.nBlockSize=41729 mp3.nFramesPerBlock=256 mp3.nCodecDelay=28933 ========================================================================== list_end=0x264 AVI: dmlh found (size=244) (total_frames=1319) list_end=0xA9624E Found movie at 0x80C - 0xA9624E Reading INDEX block, 2626 chunks for 1319 frames (fpos=11100758). AVI index offset: 0x808 (movi=0x80C idx0=0x4 idx1=0x1F4C) Auto-selected AVI audio ID = 1 Auto-selected AVI video ID = 0 AVI: Searching for audio stream (id:1) AVI video size=10196805 (1319) audio size=879574 (879574) VIDEO: [DX50] 848x352 24bpp 23.975 fps 1482.7 kbps (181.0 kbyte/s) [V] filefmt:3 fourcc:0x30355844 size:848x352 fps:23.98 ftime:=0.0417 get_path('sub/') -> '/root/.mplayer/sub/' using /dev/fb0 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family INFO: libavcodec init OK! Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 dec_audio: Allocating 4608 + 65536 = 70144 bytes for output buffer. mp3lib: using AltiVec optimized decore! MP3lib: init layer2&3 finished, tables done MPEG 1.0, Layer III, 44100 Hz 128 kbit Joint-Stereo, BPF: 418 Channels: 2, copyright: No, original: No, CRC: No, emphasis: 0 AUDIO: 44100 Hz, 2 ch, s16be, 128.0 kbit/9.07% (ratio: 16000->176400) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== Building audio filter chain for 44100Hz/2ch/s16be -> 0Hz/0ch/??... [libaf] Adding filter dummy [dummy] Was reinitialized: 44100Hz/2ch/s16be [dummy] Was reinitialized: 44100Hz/2ch/s16be ao2: 44100 Hz 2 chans s16be audio_setup: using '/dev/dsp' dsp device audio_setup: using '/dev/mixer' mixer device audio_setup: using 'pcm' mixer device audio_setup: sample format: s16be (requested: s16be) audio_setup: using 2 channels (requested: 2) audio_setup: using 44100 Hz samplerate (requested: 44100) audio_setup: frags: 2/2 (4104 bytes/frag) free: 8208 AO: [oss] 44100Hz 2ch s16be (2 bytes per sample) AO: Description: OSS/ioctl audio output AO: Author: A'rpi Building audio filter chain for 44100Hz/2ch/s16be -> 44100Hz/2ch/s16be... [dummy] Was reinitialized: 44100Hz/2ch/s16be [dummy] Was reinitialized: 44100Hz/2ch/s16be Starting playback... Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. You may try recompiling using gcc >= 4.2. Do not report crashes to FFmpeg developers. [ffmpeg] aspect_ratio: 2.409091 VDec: vo config request - 848 x 352 (preferred colorspace: Planar YV12) Trying filter chain: vo Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] SwScale params: -1 x -1 (-1=no scaling) Trying filter chain: scale vo VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 2.41:1 - prescaling to correct movie aspect. VO Config (848x352->848x352,flags=0,'MPlayer',0x32315659) [swscaler @ 0x1068d964]ALTIVEC: Color Space ARGB [swscaler @ 0x1068d964]SwScaler: using unscaled yuv420p -> rgb32 special converter REQ: flags=0x403 req=0x0 VO: [fbdev] 848x352 => 848x352 ARGB VO: Description: Framebuffer Device VO: Author: Szabolcs Berecz szabi@inf.elte.hu Can't set graphics mode: Invalid argument var info: xres: 1280 yres: 1024 xres_virtual: 1280 yres_virtual: 1024 xoffset: 0 yoffset: 0 bits_per_pixel: 32 grayscale: 0 red: 16 8 0 green: 8 8 0 blue: 0 8 0 transp: 24 8 0 nonstd: 10 fix info: framebuffer size: 5242880 bytes type: 0 type_aux: 0 visual: 2 line_length: 5120 bytes fb_bpp: 32 fb_pixel_size: 4 bytes other: in_width: 848 in_height: 352 out_width: 848 out_height: 352 first_row: 0 last_row: 352 Uninit video: ffmpeg
Clemens Ladisch wrote:
Timur Tabi wrote:
It turns out that ALSA (when using mplayer to play a divx video file via OSS emulation) is rapidly sending back-to-back SNDRV_PCM_TRIGGER_STOP and SNDRV_PCM_TRIGGER_START commands. Why would it do that?
To recover from underruns.
I've added some function traces to ALSA, and apparently ALSA is telling the driver to STOP when the driver calls snd_pcm_period_elapsed(). Here's a log:
snd_pcm_period_elapsed snd_pcm_update_hw_ptr_interrupt:232 <- last line of this function PERIOD <- printk in the driver's ISR snd_pcm_period_elapsed snd_pcm_update_hw_ptr_interrupt:232 snd_pcm_update_hw_ptr_post xrun snd_pcm_stop snd_pcm_action snd_pcm_action_single snd_pcm_do_stop STOP 279 <- command to stop after sub-buffer #279, which is at the end of the period
Unfortunately, very little of the code in sound/core/pcm???.c is documented, so I'm having a hard time figuring out what's going on. Why is ALSA telling the driver to stop during a period interrupt?
participants (4)
-
Clemens Ladisch -
James Courtier-Dutton -
Takashi Iwai -
Timur Tabi