hi,
i think somethings gone wrong with via82cxxx_audio. Playing anything
through it seems to cause massive latency in apps like xmms, esd,
asmixer, etc.. anything to do with playing or mixer levels suddenly
takes a minute or more to respond.
It didn't always do this, and when it started happening i assumed it
was either something bad in esd or xmms (which i tend to upgrade a
lot). However it still happens when esd is disabled. eg, i use mpg123
to play an mp3 file, and asmixer doesn't change the volume till a
minute or two after i moused it.
if i SIGSTOP mpg123, asmixer immediately becomes responsive again and
implements the pending volume change, as soon i SIGCONT mpg123,
asmixer becomes very unresponsive again.
same thing with esd, if i STOP mpg123, other apps like esd and
non-esd mixers become responsive, soon as i start playing again they
go unresponsive.
same thing with playing from esd applications, everything inlcuding
the playing app itself (eg xmms) is unresponsive, if i STOP it, the
mixers instantly become responsive, soon as i CONT the playing app
everything is "dead" again.
kernel is test12-final. AMD K7, Asus K7M board
[root@fogarty /root]# lspci -vv -s 00:04.5
00:04.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
[Apollo Super AC97/Audio] (rev 21)
Subsystem: Asustek Computer, Inc.: Unknown device 800d
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 10
Region 0: I/O ports at d400 [size=256]
Region 1: I/O ports at d000 [size=4]
Region 2: I/O ports at cc00 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
[root@fogarty /root]# cat /proc/interrupts
CPU0
0: 1064556 XT-PIC timer
1: 18405 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 904332 XT-PIC eth0
8: 1 XT-PIC rtc
10: 75896 XT-PIC BusLogic BT-958, via82cxxx
12: 278174 XT-PIC PS/2 Mouse
14: 3258 XT-PIC ide0
15: 387918 XT-PIC ide1
NMI: 0
ERR: 0
the via is sharing an interrupt, though normally the buslogic is not
being used. (the interrupt sharing has been there a lot longer than
this problem)
i don't have the /proc/driver/via.... files that the docs mention.
regards,
--
Paul Jakma [email protected] [email protected]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
And they shall beat their swords into plowshares, for if you hit a man
with a plowshare, he's going to know he's been hit.
On Wed, 13 Dec 2000, Paul Jakma wrote:
> hi,
>
> i think somethings gone wrong with via82cxxx_audio. Playing anything
> through it seems to cause massive latency in apps like xmms, esd,
> asmixer, etc.. anything to do with playing or mixer levels suddenly
> takes a minute or more to respond.
Same here. Kernel is test12-pre8 and board is an Epox 8KTA2 (VIA KT133
chipset). The funny thing is that audio itself doesnt get blocked, just XMMS'
GUI.
> the via is sharing an interrupt, though normally the buslogic is not
> being used. (the interrupt sharing has been there a lot longer than
> this problem)
>
> i don't have the /proc/driver/via.... files that the docs mention.
I will take a look into this when I'm at home (at the offending machine).
Nils
--
Nils Philippsen / Berliner Stra?e 39 / D-71229 Leonberg // +49.7152.209647
[email protected] / [email protected] / [email protected]
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence. -- Edsger W. Dijkstra
On Wed, 13 Dec 2000, Nils Philippsen wrote:
> Same here. Kernel is test12-pre8 and board is an Epox 8KTA2 (VIA KT133
> chipset). The funny thing is that audio itself doesnt get blocked, just XMMS'
> GUI.
>
it seems to happen across the board, ie whenever sound is being
played all apps that are holding any /dev/sound/ devices open become
unresponive. xmms, asmixer, mpg123, esd, etc.. etc..
> Nils
>
regards,
--
Paul Jakma [email protected] [email protected]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
Marvelous! The super-user's going to boot me!
What a finely tuned response to the situation!
On Wed, 13 Dec 2000, Nils Philippsen wrote:
> Same here. Kernel is test12-pre8 and board is an Epox 8KTA2 (VIA KT133
> chipset). The funny thing is that audio itself doesnt get blocked, just XMMS'
> GUI.
same for me, the audio plays fine, but xmms is completely
unresponsive, as is the gnome mixer, as is asmixer. (ie everything to
do with esd or /dev/sound). soon as i SIGSTOP the playing app all the
other apps come back to life.
regards,
--
Paul Jakma [email protected] [email protected]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
Parts that positively cannot be assembled in improper order will be.
Paul Jakma wrote:
> hi,
>
> i think somethings gone wrong with via82cxxx_audio. Playing anything
> through it seems to cause massive latency in apps like xmms, esd,
> asmixer, etc.. anything to do with playing or mixer levels suddenly
> takes a minute or more to respond.
>
> It didn't always do this, and when it started happening i assumed it
> was either something bad in esd or xmms (which i tend to upgrade a
> lot). However it still happens when esd is disabled. eg, i use mpg123
> to play an mp3 file, and asmixer doesn't change the volume till a
> minute or two after i moused it.
>
> if i SIGSTOP mpg123, asmixer immediately becomes responsive again and
> implements the pending volume change, as soon i SIGCONT mpg123,
> asmixer becomes very unresponsive again.
>
> same thing with esd, if i STOP mpg123, other apps like esd and
> non-esd mixers become responsive, soon as i start playing again they
> go unresponsive.
>
> same thing with playing from esd applications, everything inlcuding
> the playing app itself (eg xmms) is unresponsive, if i STOP it, the
> mixers instantly become responsive, soon as i CONT the playing app
> everything is "dead" again.
>
> kernel is test12-final. AMD K7, Asus K7M board
>
> [root@fogarty /root]# lspci -vv -s 00:04.5
> 00:04.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
> [Apollo Super AC97/Audio] (rev 21)
> Subsystem: Asustek Computer, Inc.: Unknown device 800d
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>
>> TAbort- <TAbort- <MAbort- >SERR- <PERR-
>
> Interrupt: pin C routed to IRQ 10
> Region 0: I/O ports at d400 [size=256]
> Region 1: I/O ports at d000 [size=4]
> Region 2: I/O ports at cc00 [size=4]
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> [root@fogarty /root]# cat /proc/interrupts
> CPU0
> 0: 1064556 XT-PIC timer
> 1: 18405 XT-PIC keyboard
> 2: 0 XT-PIC cascade
> 3: 904332 XT-PIC eth0
> 8: 1 XT-PIC rtc
> 10: 75896 XT-PIC BusLogic BT-958, via82cxxx
> 12: 278174 XT-PIC PS/2 Mouse
> 14: 3258 XT-PIC ide0
> 15: 387918 XT-PIC ide1
> NMI: 0
> ERR: 0
>
> the via is sharing an interrupt, though normally the buslogic is not
> being used. (the interrupt sharing has been there a lot longer than
> this problem)
>
> i don't have the /proc/driver/via.... files that the docs mention.
>
> regards,
Oh my, I am SO glad someone else noticed this! I was not going to say
anything because I thought _I_ was crazy. I burnt out my CPU yesterday
in a nasty experiment (don't ask!) and had to go out and buy a new
MB/CPU. I bought the ASUS CUV4X with sound. Lo and behold it has the
VIA VT82C686A audio. I get my new system running just great, load this
driver, then go do my favorite pastime: Frag in Unreal Tournament for
Linux! Man was the sound delayed! I tried 4 Front's driver too with
the same results which made me think that this setup really sucked!
I am all set to put a Creative 128 in the system and I stumbled onto
this message. :-)
Johnny O
--
<SomeLamer> what's the difference between chattr and chmod?
<SomeGuru> SomeLamer: man chattr > 1; man chmod > 2; diff -u 1 2 | less
-- Seen on #linux on irc
=== Never ask a geek why, just nod your head and slowly back away.===
+==============================+====================================+
| John O'Donnell (Sr. Systems Engineer, Net Admin, Webmaster, etc.) |
| Voice FX Corporation (a subsidiary of Student Advantage) |
| One Plymouth Meeting | E-Mail: [email protected] |
| Suite 610 | http://www.voicefx.com |
| Plymouth Meeting, PA 19462 | http://www.campusdirect.com |
+==============================+====================================+
Paul Jakma wrote:
>
> hi,
>
> i think somethings gone wrong with via82cxxx_audio. Playing anything
> through it seems to cause massive latency in apps like xmms, esd,
> asmixer, etc.. anything to do with playing or mixer levels suddenly
> takes a minute or more to respond.
>
> It didn't always do this, and when it started happening i assumed it
> was either something bad in esd or xmms (which i tend to upgrade a
> lot). However it still happens when esd is disabled. eg, i use mpg123
> to play an mp3 file, and asmixer doesn't change the volume till a
> minute or two after i moused it.
>
> if i SIGSTOP mpg123, asmixer immediately becomes responsive again and
> implements the pending volume change, as soon i SIGCONT mpg123,
> asmixer becomes very unresponsive again.
>
> same thing with esd, if i STOP mpg123, other apps like esd and
> non-esd mixers become responsive, soon as i start playing again they
> go unresponsive.
>
> same thing with playing from esd applications, everything inlcuding
> the playing app itself (eg xmms) is unresponsive, if i STOP it, the
> mixers instantly become responsive, soon as i CONT the playing app
> everything is "dead" again.
>
> kernel is test12-final. AMD K7, Asus K7M board
>
> the via is sharing an interrupt, though normally the buslogic is not
> being used. (the interrupt sharing has been there a lot longer than
> this problem)
I ran into the same problems with the same driver. Sharing an interrupt
isn't the problem, it's just a really young driver. The ALSA driver
works fine, but I switched to an Ensoniq/Creative PCI card because I
found that the chipset just clipped like mad anyway (just cheapness, I
suppose, or maybe I'm doing something wrong) when mixing sounds together
(as in Quake3 or esd). If you want to use it, though, I'd suggest using
ALSA. It works. Alternatively, you could fix the OSS driver.