reassign 574844 mplayer,libasound2 tags 574844 help stop Hi,
On Wed, Apr 07, 2010 at 01:41:24 (EDT), trentb...@gmail.com wrote: > # New evidence suggests this problem is mplayer-specific. > reassign 575844 mplayer > found 575844 1.0~rc3+svn20090405-1+b1 > thanks > > Consider the following transcript. First, we generate a test file: > > $ mplayer -really-quiet -ao pcm:fast -vo null -vc null > http://he3.magnatune.com/all/01-Aurore-Gerard%20Satamian-lofi.mp3 > > Plain aplay works: > > $ sleep 10 && sudo tee <<<mem /sys/power/state & aplay audiodump.wav > [1] 5764 > Playing WAVE 'audiodump.wav' : Signed 16 bit Little Endian, Rate 22050 > Hz, Stereo > mem > Suspended. Trying resume. Done. > underrun!!! (at least -1270530282992.973 ms long) > C-c C-cAborted by signal Interrupt... > [1]+ Done sleep 10 && sudo tee /sys/power/state <<< > mem > > Hmm, this works, too, though the delay between resuming the system and > the audio continuing to play is much longer than with aplay. This may or may not be caused by the resume code in mplayer: ,----[libao2/ao_alsa.c] | static void audio_resume(void) | { | int err; | | if (snd_pcm_state(alsa_handler) == SND_PCM_STATE_SUSPENDED) { | mp_msg(MSGT_AO,MSGL_INFO,MSGTR_AO_ALSA_PcmInSuspendModeTryingResume); | while ((err = snd_pcm_resume(alsa_handler)) == -EAGAIN) sleep(1); | } | if (alsa_can_pause) { | if ((err = snd_pcm_pause(alsa_handler, 0)) < 0) | { | mp_msg(MSGT_AO,MSGL_ERR,MSGTR_AO_ALSA_PcmResumeError, snd_strerror(err)); | return; | } | mp_msg(MSGT_AO,MSGL_V,"alsa-resume: resume supported by hardware\n"); | } else { | if ((err = snd_pcm_prepare(alsa_handler)) < 0) | { | mp_msg(MSGT_AO,MSGL_ERR,MSGTR_AO_ALSA_PcmPrepareError, snd_strerror(err)); | return; | } | } | } `---- > $ sleep 10 && sudo tee <<<mem /sys/power/state & mplayer > -noconsolecontrols -quiet audiodump.wav > [1] 2832 > MPlayer SVN-r29142-4.4.3 (C) 2000-2009 MPlayer Team > > Playing audiodump.wav. > Audio only file format detected. > ========================================================================== > Opening audio decoder: [pcm] Uncompressed PCM audio decoder > AUDIO: 22050 Hz, 2 ch, s16le, 705.6 kbit/100.00% (ratio: 88200->88200) > Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) > ========================================================================== > AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) > Video: no video > Starting playback... > mem > [AO_ALSA] Pcm in suspend mode, trying to resume. > [AO_ALSA] alsa-lib: pcm_hw.c:709:(snd_pcm_hw_resume) > SNDRV_PCM_IOCTL_RESUME failed: Function not implemented > C-c C-c > > MPlayer interrupted by signal 2 in module: play_audio > > Exiting... (Quit) > [1]+ Done sleep 10 && sudo tee /sys/power/state <<< > mem > > But this doesn't: > > $ sleep 10 && sudo tee <<<mem /sys/power/state & mplayer audiodump.wav > [1] 5698 > MPlayer SVN-r29142-4.4.3 (C) 2000-2009 MPlayer Team > > Playing audiodump.wav. > Audio only file format detected. > ========================================================================== > Opening audio decoder: [pcm] Uncompressed PCM audio decoder > AUDIO: 22050 Hz, 2 ch, s16le, 705.6 kbit/100.00% (ratio: 88200->88200) > Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) > ========================================================================== > AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) > Video: no video > Starting playback... > mem > [AO_ALSA] Pcm in suspend mode, trying to resume. > [AO_ALSA] alsa-lib: pcm_hw.c:709:(snd_pcm_hw_resume) > SNDRV_PCM_IOCTL_RESUME failed: Function not implemented > C-c C-c > > MPlayer interrupted by signal 2 in module: play_audio > C-c C-c > > MPlayer interrupted by signal 2 in module: play_audio > [1]+ Done sleep 10 && sudo tee /sys/power/state <<< > mem > > This makes me suspect some part of mplayer's terminal interaction > code. AFAIU the code, -noconsolecontrols does not do any terminal handling, but 'just' controls on what events mplayer reacts. this is mainly useful for the slave mode. I'm still a bit surprised why this makes a difference here. > These tests were done within Emacs' M-x shell, where TERM=dumb and > stdio is connected to a tty (i.e. "test -t 0 -a -t 1 -a -t 2" passes). > > The behaviour above is consistent for kernels > linux-image-2.6.32-3-amd64 (2.6.32-9) and linux-image-2.6.33-2-amd64 > (2.6.33-1~experimental.4). For each, alsa-info.sh yields > http://www.alsa-project.org/db/?f=3d1754592d25ecf773a04984473c7eefeda581de > http://www.alsa-project.org/db/?f=df81bc3978db0e9a08685581da7614548dd41acc in any case, this clearly needs an alsa expert. To me, this is clearly an error from alsa-lib. I'm therefore reassinging this to both packages, but I can also imagine that this needs to be fixed in the kernel. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org