Bug 7694 - Audigy NX normal playback impossible
Audigy NX normal playback impossible
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: USB
i386 Linux
: P2 high
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks: USB
  Show dependency treegraph
 
Reported: 2006-12-16 14:41 UTC by Denis Zalewsky
Modified: 2008-08-30 13:47 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.17
Tree: Mainline
Regression: ---


Attachments
Patch for this bug (2.61 KB, patch)
2008-04-15 14:00 UTC, Herton Ronaldo Krzesinski
Details | Diff

Description Denis Zalewsky 2006-12-16 14:41:37 UTC
Most recent kernel where this bug did *NOT* occur:

Distribution: Gentoo 

Hardware Environment: 

Dell Inspiron 700m
i686 Intel(R) Pentium(R) M processor 1.60GHz

$lsusb
Bus 004 Device 007: ID 041e:3020 Creative Technology, Ltd SoundBlaster Audigy 2 NX
Bus 004 Device 005: ID 0566:3002 Monterey International Corp.
Bus 004 Device 004: ID 04d9:0499 Holtek Semiconductor, Inc.
Bus 004 Device 003: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 004 Device 002: ID 05e3:0606 Genesys Logic, Inc.

$lspci
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to
I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor
to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor
to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics
Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge
(rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97
Modem Controller (rev 03)
02:01.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
02:04.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
02:04.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
02:04.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port
PHY/Link-Layer Controller
02:04.3 Mass storage controller: <pci_lookup_name: buffer too small>
02:05.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)



Software Environment:

Problem Description: playback through module usbaudio using Audigy NX breaks
approx. 1 time in 10-15 sec and continues ~2 sec later skipping several seconds
of sound. Looking into kernel execution shows that usb driver returns EL2NSYNC
in snd_complete_sync_urb() that calls snd_pcm_stop().

Steps to reproduce: play sound longer than ~20 sec by means of any audio player

P.S. It seems exactly similar problem has been discussed in threads "[PATCH
15/15] usbaudio retries EL2NSYNC" and "[PATCH 15/15] ehci-hcd: full-featured
EHCI budgeter/scheduler" (e.g. see
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47614.html )
Comment 1 Monty 2006-12-17 11:18:33 UTC
It's not the same problem as being discussed in those threads.  

The thread "[PATCH 15/15] usbaudio retries EL2NSYNC" is a temporary workaround
for a bug caused by/exposed by the new scheduler patch, which is not yet in any
mainline kernel, and happens only before playback begins.

The thread "PATCH 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler" is
relevant primarily because it entirely replaces the code that can return that
error (as the existing code in the mainline kernel appears to be broken in that
I can't figure out what it intends to do).


Monty
Comment 2 Natalie Protasevich 2007-06-13 18:59:37 UTC
Any updates on the problem? Does it still exist with latest kernel?
Thanks.
Comment 3 Denis Zalewsky 2007-06-13 22:29:08 UTC
If I apply the following changes everything works fine. Anyway the whole control flow branch where this patch applied performs some calculations w/o any practical result. And to understand what is the better way to fix first I should understand why this code has been added sometimes before. Maybe it is rather old and deprecated but maybe it is still actual.

--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1347,7 +1347,7 @@ iso_stream_schedule (
 	if (likely (!list_empty (&stream->td_list))) {
 		start = stream->next_uframe;
 		if (start < now)
-			start += mod;
+			start = now;
 		if (likely ((start + sched->span) < max))
 			goto ready;
 		/* else fell behind; someday, try to reschedule */
Comment 4 Natalie Protasevich 2007-06-13 23:04:37 UTC
This will be definitely useful for the developers to know, adding appropriate people...
Comment 5 Natalie Protasevich 2008-04-14 01:07:08 UTC
Denis, if the problem still present with the latest kernel, can you post your patch and question to lkml please.
Comment 6 Herton Ronaldo Krzesinski 2008-04-15 14:00:01 UTC
Created attachment 15761 [details]
Patch for this bug

Can you try this patch from Alan Stern? It seems what will address this. Accordingly to Laurent Pinchart probably the patch will go into 2.6.26
Comment 7 Denis Zalewsky 2008-04-17 15:02:15 UTC
Thank you! I will try it and report results
Comment 8 Herton Ronaldo Krzesinski 2008-04-22 20:05:16 UTC
This could be fixed too with 2.6.25 without the patch, at least for uvcvideo seems the case. Please test without the patch on a 2.6.25 kernel too.
Comment 9 David Brownell 2008-08-26 12:43:03 UTC
Fixed by b40e43fcc532fa44a375a37d592e32cd0d50fe7a yes?  If nobody says otherwise, we'll assume this bug is now fixed...
Comment 10 Denis Zalewsky 2008-08-26 23:59:57 UTC
I have tested on vanilla 2.6.25 and the issue exists there and it seems became more prominent.
So, now I should try to build with attached patch and with b40e43fcc532fa44a375a37d592e32cd0d50fe7a.
Comment 11 Denis Zalewsky 2008-08-27 00:15:36 UTC
2 David Brownell:

In which repository b40e43fcc532fa44a375a37d592e32cd0d50fe7a exists? I see Linus repository doesn't contain it yet.
Comment 12 David Brownell 2008-08-27 00:32:55 UTC
b40e43fcc532fa44a375a37d592e32cd0d50fe7a has been in mainline for long enough that its date says "May 20 2008".  Which is FWIW after 2.6.25 froze...

I have no idea why you're looking at 2.6.25 when 2.6.27-rc4 is current.
Comment 13 Denis Zalewsky 2008-08-27 13:18:28 UTC
2 David Brownell:
regarding 2.6.25: it was reply to previous post of Herton Ronaldo Krzesinski, look for previous comments.
Comment 14 Denis Zalewsky 2008-08-30 13:47:05 UTC
I can confirm the issue is not actual in 2.6.26 (where b40e43fcc532fa44a375a37d592e32cd0d50fe7a is included) and can be closed.

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