Bug 6576
| Summary: | USB sound card does not work | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Pavel Machek (pavel) |
| Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | akpm, alan, huangjq, oliver, protasnb, tiwai |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.25-rc6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
While it pretends to be playing 44.1kHz mp3 (using mpg123) (I hear nothing, as usual). pavel@amd:/proc/asound/card1/pcm0p/sub0$ cat sw_params tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 1 xfer_align: 1 start_threshold: 1 stop_threshold: 787200 silence_threshold: 24616 silence_size: 24616 boundary: 1612185600 pavel@amd:/proc/asound/card1/pcm0p/sub0$ cat hw_params access: RW_INTERLEAVED format: S8 subformat: STD channels: 1 rate: 48000 (48000/1) period_size: 24600 buffer_size: 787200 tick_time: 4000 OSS format: U8 OSS channels: 1 OSS rate: 8000 OSS period bytes: 4096 OSS periods: 32 OSS period frames: 24600 pavel@amd:/proc/asound/card1/pcm0p/sub0$ cat status state: RUNNING trigger_time: 1147907133.318794000 tstamp : 1147907199.343597000 delay : 766078 avail : 21122 avail_max : 762600 ----- hw_ptr : 3169937 appl_ptr : 3936015 pavel@amd:/proc/asound/card1/pcm0p/sub0$ pavel@amd:/proc/asound/card1/pcm0p/sub0$ cat info card: 1 device: 0 subdevice: 0 stream: PLAYBACK id: USB Audio name: USB Audio subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 alsaplayer -F8000 -d /dev/dsp1 ...mp3 Failed to load output plugin "alsa". Trying defaults. ...and alsaplayer happily seems to play at 8kHz even through the card only supports 48kHz, AFAICT. should not kernel return error or something? How is the output of "lsusb -v", and the contents of /proc/asound/card1/stream* fiels? The usbaudio driver has a special workaround for the usb ID 04fa:4201, which is known as a Dallas DS4201. It has a h/w bug using signed 8bit format instead of unsigned 8bit. Is this your device? Reply-To: pavel@ucw.cz > ------- Additional Comments From tiwai@suse.de 2006-05-22 04:21 ------- > How is the output of "lsusb -v", and the contents of /proc/asound/card1/stream* > fiels? lsusb does not work here :-(. I have no stream* files: root@hobit:~# ls /proc/asound/card*/str* ls: /proc/asound/card*/str*: No such file or directory root@hobit:~# > The usbaudio driver has a special workaround for the usb ID 04fa:4201, which is > known as a Dallas DS4201. It has a h/w bug using signed 8bit format instead of > unsigned 8bit. Is this your device? But I seem to have affected device: lrwxrwxrwx 1 root root 5 May 23 09:53 /proc/asound/U0x4fa0x4201 -> card0/ ping? Yes, I believe that still happens. We are currently trying to debug it with takashi... latest show-stopper seem to be some problems with mixer. alsamixer fails for some reason. (takashi said):
> I still don't know exactly what the problem is. The ioctl error
> may occur when the response from the device is somewhat unexpected and
> errorous. Try to uncomment IGNORE_CTL_ERROR in sound/usb/usbmixer.c
> in such a case...
Well, that enables me to launch an alsamixer, but that's it, still no
sound. I unmuted / set to max everything I could, and tried playing
both 48kHz and 44kHz samples...
How is it doing now with 2.6.22-rc4 or 5? Thanks - --Natalie If the problem still there, please reopen this bug, then if confirmed with latest kernel it will be sent to ALSA list. ...still there, with 2.6.25-rc6. From: Pavel Machek <pavel@ucw.cz> To: Takashi Iwai <tiwai@suse.de>, kernel list <linux-kernel@vger.kernel.org> Subject: USB-audio strange problems X-Warning: Reading this can be dangerous to your mental health. Hi! Ok, so it took me a year to get back to this bug. Oops. > Yep, let's fix it. Just to make sure (ane debugging easy atm), could > you attach the following? > > - content of /proc/asound/cards > - content of /proc/asound/card*/stream* > - the output of "lsusb -v" > - the generated file via "alsactl -f store somefile" > > If I remember correctly, alsamixer at least doesn't break if you build > snd-usb-audio driver with IGNORE_CTL_ERR enabled, right? I got the usb soundcard to work. I still have IGNORE_CTL_ERR enabled. Problem was not mixer after all... somehow it expects me to play sound as 8-bit, and then I can play 16-bit mono and actually hear it. _Strange_. So:mplayer -ao alsa:device=hw=0 -af format=u8 KDE_Startup.wav mplayer -ao alsa:device=hw=0 -af format=s16le -af resample=48000 -af channels=1 +KDE_Logout_1.ogg ...plays both files. Forget about the first mplayer, and it will play nothing. Files you asked for: hobit:/usr/share/sounds# cat /proc/asound/cards 0 [U0x4fa0x4201 ]: USB-Audio - USB Device 0x4fa:0x4201 USB Device 0x4fa:0x4201 at usb-0000:00:1a.0-1, full speed (rest of lists are in lkml archives, too big to paste here). > > But problem is: I have to. Otherwise the second mplayer will produce > > just silence. > > How about "-ao alsa:device=plughw=0 -af format=u8" ? mplayer -ao alsa:device=plughw=0 -af format=u8 KDE_Startup.wav ...is silent mplayer -ao alsa:device=hw=0 -af format=u8 KDE_Startup.wav ...I can hear it. (What's difference between hw and plughw?) > > Also, even with that treatment, I'm unable to play stereo :-(. > > What shows stream* proc file while playing a 16bit stereo file? I test by: mplayer -ao alsa:device=hw=0 -af format=s16le -af resample=48000 KDE_Logout_1.ogg hobit:/proc/asound# grep . */stream* U0x4fa0x4201/stream0:USB Device 0x4fa:0x4201 at usb-0000:00:1a.0-1, full speed : USB Audio U0x4fa0x4201/stream0:Playback: U0x4fa0x4201/stream0: Status: Running U0x4fa0x4201/stream0: Interface = 1 U0x4fa0x4201/stream0: Altset = 5 U0x4fa0x4201/stream0: URBs = 3 [ 8 8 6 ] U0x4fa0x4201/stream0: Packet Size = 196 U0x4fa0x4201/stream0: Momentary freq = 48000 Hz (0x30.0000) ... (rest of post on lkml, too big) ...strange. I realized it consistently works in mono if I plug speakers directly to usb port. It consistently fails in stereo, or if I plug speakers into (self-powered) hub. mplayer in u8 format was red herring: mplayer saw it is not supported by hardware, so it fell back to s16le... and worked because test file I was using was mono. Verified on 2.6.25-rc7: if I play stereo, everything seems ok, no messages in syslog, and no sound. Mono plays well. Does it work on the hub if you unload ehci_hcd? 2channels, s8 playback seems to work (and I can hear it) 1channel, s8 playback _seems_ to work, but I can't hear anything. (both with ehci present, will try removing ehci) I compiled out EHCI support. It did not fix the playback in hub. What's stranger, after few plugs/unplugs, USB audio is no longer detected when plugged directly in. Still detected in a hub (where it does not work :-(). Okay, I moved my tests to thinkpad x60... the previous machine probably has some unrelated USB problems... Here it plays both directly plugged in and in a hub, but only in s16le,1ch mode. select 2 channels, and it only plays silence. It gets weirder. Moved tests back to intel notabook, and it works even in a hub... as long as I plug the speakers before the mouse and bluetooth card. _Weird_. Hmm, difference may be that notabook had powered hub. In unpowered configuration, bluetooth card refuses to work, and speakers work...
Something seems to be very wrong with that machine ("intel
notabook"). If I get rid of EHCI, newly plugged devices are not
recognized, including for example that hub..
Reply-To: pavel@ucw.cz Got some more debug info: In the working case hub 2-1:1.0: state 7 ports 4 chg 0000 evt 0010 hub 2-1:1.0: port 4, status 0101, change 0001, 12 Mb/s hub 2-1:1.0: debounce: port 4: total 100ms stable 100ms status 0x101 usb 2-1.4: new full speed USB device using uhci_hcd and address 5 usb 2-1.4: ep0 maxpacket = 8 usb 2-1.4: skipped 10 descriptors after interface usb 2-1.4: skipped 2 descriptors after interface usb 2-1.4: skipped 1 descriptor after endpoint usb 2-1.4: skipped 2 descriptors after interface usb 2-1.4: skipped 1 descriptor after endpoint usb 2-1.4: skipped 2 descriptors after interface usb 2-1.4: skipped 1 descriptor after endpoint usb 2-1.4: skipped 2 descriptors after interface usb 2-1.4: skipped 1 descriptor after endpoint usb 2-1.4: skipped 2 descriptors after interface usb 2-1.4: skipped 1 descriptor after endpoint usb 2-1.4: uevent usb 2-1.4: usb_probe_device usb 2-1.4: configuration #1 chosen from 1 choice usb 2-1.4: adding 2-1.4:1.0 (config #1, interface 0) usb 2-1.4:1.0: uevent snd-usb-audio 2-1.4:1.0: usb_probe_interface snd-usb-audio 2-1.4:1.0: usb_probe_interface - got id usb 2-1.4: adding 2-1.4:1.1 (config #1, interface 1) usb 2-1.4:1.1: uevent /data/l/linux/drivers/usb/core/inode.c: creating file '005' usb 2-1.4: New USB device found, idVendor=04fa, idProduct=4201 usb 2-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 2-1:1.0: 300mA power budget left hub 2-1:1.0: state 7 ports 4 chg 0000 evt 0010 have format: format = 2, rate = 44100..48000, channels = 2, attr = 5 datapipe = 0x0, syncpipe = 0x0 have format: format = 2, rate = 44100..48000, channels = 1, attr = 5 datapipe = 0x0, syncpipe = 0x0 *** found suitable candidate *** found suitable format have format: format = 0, rate = 44100..48000, channels = 2, attr = 5 datapipe = 0x0, syncpipe = 0x0 have format: format = 0, rate = 44100..48000, channels = 1, attr = 5 datapipe = 0x0, syncpipe = 0x0 have format: format = 2, rate = 44100..48000, channels = 2, attr = 9 datapipe = 0x0, syncpipe = 0x0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # two very similar formats, but if I choose either one, it does not # play in stereo setting usb interface 1:2 setting done: format = 2, rate = 44100..48000, channels = 1 datapipe = 0x8500, syncpipe = 0x10580 ~~~~~~~~~~~~~~~~~~ # in failing case, there's no syncpipe, # there's 0 here. uhci_hcd 0000:00:1d.0: reserve dev 5 ep01-ISO, period 1, phase 0, 84 us uhci_hcd 0000:00:1d.0: reserve dev 5 ep82-ISO, period 64, phase 1, 11 us uhci_hcd 0000:00:1d.0: release dev 5 ep82-ISO, period 64, phase 1, 11 us ~~~~~~~~~~~ # and these two are not present. uhci_hcd 0000:00:1d.0: release dev 5 ep01-ISO, period 1, phase 0, 84 us Is it possible that syncpipe is required for actually hearing the sound? Is there an easy way to force the syncpipe? Reply-To: oliver@neukum.org Am Freitag, 28. März 2008 00:18:28 schrieb bugme-daemon@bugzilla.kernel.org: > http://bugzilla.kernel.org/show_bug.cgi?id=6576 > Okay, I moved my tests to thinkpad x60... the previous machine probably has > some unrelated USB problems... Here it plays both directly plugged in and in > a > hub, but only in s16le,1ch mode. select 2 channels, and it only plays > silence. OK, the next step is to get a usbmon trace in the failure case to check whether the iso transfers go out onto the bus and contain the payload they should. Reply-To: pavel@ucw.cz Hi! I got it to work in stereo. Problem seems to be... it has 5 configurations, and only 4 of them work. usbaudio.c: @@ -2676,7 +2699,7 @@ static int parse_audio_endpoints(struct /* parse the interface's altsettings */ iface = usb_ifnum_to_if(dev, iface_no); - for (i = 0; i < iface->num_altsetting; i++) { + for (i = 0; i < 4; i++) { alts = &iface->altsetting[i]; altsd = get_iface_desc(alts); /* skip invalid one */ ...this makes it work for me. (Ok, unless it is one of about 100 other hacks I did.) Reply-To: pavel@ucw.cz Here's mostly clean patch, you have one with changelogs in your inbox. There's still a glitch where the speakers produce no sound if you try to use them too quickly after plugging them in. I guess that is different from this problem... and I think I can live with it. diff --git a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c index b7f5465..b6b2490 100644 --- a/sound/usb/usbaudio.c +++ b/sound/usb/usbaudio.c @@ -2470,11 +2470,12 @@ static int parse_audio_format_i_type(str } break; case USB_AUDIO_FORMAT_PCM8: - /* Dallas DS4201 workaround */ + pcm_format = SNDRV_PCM_FORMAT_U8; + + /* Dallas DS4201 workaround: it advertises U8 format, but really + supports S8. */ if (chip->usb_id == USB_ID(0x04fa, 0x4201)) pcm_format = SNDRV_PCM_FORMAT_S8; - else - pcm_format = SNDRV_PCM_FORMAT_U8; break; case USB_AUDIO_FORMAT_IEEE_FLOAT: pcm_format = SNDRV_PCM_FORMAT_FLOAT_LE; @@ -2678,12 +2679,20 @@ static int parse_audio_endpoints(struct int format; struct audioformat *fp; unsigned char *fmt, *csep; + int num; dev = chip->dev; /* parse the interface's altsettings */ iface = usb_ifnum_to_if(dev, iface_no); - for (i = 0; i < 4; i++) { + num = iface->num_altsetting; + + /* Dallas DS4201 workaround: It presents 5 altsettings, but the last + one misses syncpipe, and does not produce any sound. */ + if (chip->usb_id == USB_ID(0x04fa, 0x4201)) + num = 4; + + for (i = 0; i < num; i++) { alts = &iface->altsetting[i]; altsd = get_iface_desc(alts); /* skip invalid one */ |
Most recent kernel where this bug did not occur: Distribution: Debian Hardware Environment: i386 linux Software Environment: Problem Description: cat /proc/asound/cards 0 [I82801DBICH4 ]: ICH4 - Intel 82801DB-ICH4 Intel 82801DB-ICH4 with AD1981B at 0xc0000c00, irq 11 1 [U0x4fa0x4201 ]: USB-Audio - USB Device 0x4fa:0x4201 USB Device 0x4fa:0x4201 at usb-0000:00:1d.1-2, full speed If I attempt to play a song using mpg123 or xmms, I get nothing, only maybe click at beggining. I'm using in-kernel OSS emulation. pavel@amd:/mnt/mp3.ptacek/Tanita_Tikaram$ cat /proc/asound/card1/pcm0p/info card: 1 device: 0 subdevice: 0 stream: PLAYBACK id: USB Audio name: USB Audio subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 pavel@amd:/mnt/mp3.ptacek/Tanita_Tikaram$ I tried unmuting everything using aumix. cat /bin/bash > /dev/dsp1 fails to produce any sound, too.