Bug 10963 - ymfpci: can't play sounds with bitrate 44100
Summary: ymfpci: can't play sounds with bitrate 44100
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-22 11:52 UTC by Akkana Peck
Modified: 2008-07-14 14:41 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.25.7
Tree: Mainline
Regression: Yes


Attachments
patch to revert to 2.6.23.17 (7.96 KB, patch)
2008-06-22 12:22 UTC, Akkana Peck
Details | Diff
Fix initialization of 44.1kHz volume (1.03 KB, patch)
2008-06-25 07:59 UTC, Takashi Iwai
Details | Diff

Description Akkana Peck 2008-06-22 11:52:03 UTC
Latest working kernel version: 2.6.23.17
Earliest failing kernel version: 2.6.24-rc5
Distribution: ubuntu 8.04
Hardware Environment: Vaio SR17
Software Environment: sox play, mpg123, vlc, mplayer etc.
Problem Description:
 Starting with 2.6.24-rc5 and continuing at least through 2.6.25.7, any sound (wav, ogg vorbis, mp3) with a bitrate of 44100 (the default for files ripped from CD) plays at zero volume -- there's no way to play these files.

Steps to reproduce:
 Play (e.g. with /usr/bin/play from sox, or any other media player) a file that uses that bitrate (I'll attach a sample). Observe that the player seems to think it's playing something, but no sound comes out.

Reverting sound/pci/ymfpci/ymfpci_main.c to the ymfpci_main.c from 2.6.23.17 cures the problem, and makes those files play properly again.
Comment 1 Akkana Peck 2008-06-22 12:06:38 UTC
Bugzilla won't let me attach the mp3 (undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58), but if you need a sample, I've put it for now at http://shallowsky.com/bugs/mocker.mp3.
Comment 2 Akkana Peck 2008-06-22 12:22:33 UTC
Created attachment 16579 [details]
patch to revert to 2.6.23.17

I'm sure this patch is more than is really needed, but it does work, in case anyone else needs it.
Comment 3 Takashi Iwai 2008-06-23 03:19:45 UTC
Do you set "Wave Playback Volume" properly?

If you still have the problem after setting "Wave" volume, run alsa-info.sh with --no-upload option and attach the generated file for further analysis.  The script is found at
    http://www.alsa-project.org/alsa-info.sh

Thanks.
Comment 4 Akkana Peck 2008-06-23 10:21:52 UTC
Yes, that's it. I installed alsamixergui and it shows two fields identically named "Wave"; when I boot off the problematic kernels, the first "Wave" field is at 100% but the second one is at zero. Setting the second Wave to 100% cures the problem for that session, but it's back at zero at the next reboot.
Comment 5 Takashi Iwai 2008-06-25 07:58:32 UTC
I don't know what mixer app you are using, but one is "Wave Playback Volume" and another is "Wave Capture Volume".

Looking through the code, I found that the initialization for 44.1kHz volume is missing.  Could you try the patch below?
Comment 6 Takashi Iwai 2008-06-25 07:59:40 UTC
Created attachment 16623 [details]
Fix initialization of 44.1kHz volume
Comment 7 Takashi Iwai 2008-06-25 08:18:50 UTC
... and I must have been blind without a coffee.  alsamixergui could be buggy regarding the handling of the same playback/capture volume.  Check alsamixer instead.  (The patch is still valid, though.)
Comment 8 Akkana Peck 2008-06-25 14:39:38 UTC
First, the patch works great. I can play the problematic clips with it without needing to adjust anything.

With the patch, alsamixergui still shows the second Wav field at zero (and the first at 100). alsamixer (non-gui), if I type F5 to show both Wav fields, shows Wav Playback at 100 and Wav Capture at 0.

So I guess it's Wav Capture that needed to be moved off 0 in order to hear sound in 2.6.25 without the patch, however odd that sounds.
Comment 9 Adrian Bunk 2008-07-14 14:41:45 UTC
fixed by commit 4a3b6983232cd296ea260e06461d031f10065d63

Note You need to log in before you can comment on or make changes to this bug.