Hello,
I would like to submit the following bug to the list.
I've compiled the brand new 2.4.1 with the i810 module (the one which plays
mp3s 15% faster than the usual speed). I did a hack modifying this line into :
/usr/src/linux/drivers/sound/i810_audio.c and modified the clocking as
follows :
static unsigned int clocking=41194;
I don't think this why i got this behavior but using xmms sucked 98% of the
CPU time reading either mp3s or ogg files. Something is definitly wrong with
this driver as ALSA ones work just fine (xmms then uses only 0.5% of the CPU
time).
hope it is useful.
Cheers
Steph
--
Email sent with RH 7.0 running kernel 241
"Go away or I will replace you with a very small shell script" - ThinkGeek
Mailto:[email protected]
Phone:8586009
> I've compiled the brand new 2.4.1 with the i810 module (the one which plays
> mp3s 15% faster than the usual speed). I did a hack modifying this line into :
> /usr/src/linux/drivers/sound/i810_audio.c and modified the clocking as
> follows :
>
> static unsigned int clocking=41194;
>
> I don't think this why i got this behavior but using xmms sucked 98% of the
> CPU time reading either mp3s or ogg files. Something is definitly wrong with
> this driver as ALSA ones work just fine (xmms then uses only 0.5% of the CPU
> time).
Or something is wrong with xmms. Right now I dont know which. I can tell you
the speed thing is unrelated. Certain vendors wire the ac97 codecs to the wrong
clock to save board space/crystals - notably dell laptops. That is why the
clocking value is a module option and you can select 'fix the sound on dell'
mode with the module option ftsodell=1
[email protected] (Alan Cox) writes:
> > I don't think this why i got this behavior but using xmms sucked 98% of the
> > CPU time reading either mp3s or ogg files. Something is definitly wrong with
> > this driver as ALSA ones work just fine (xmms then uses only 0.5% of the CPU
> > time).
>
> Or something is wrong with xmms. Right now I dont know which. I can tell you
> the speed thing is unrelated.
My patch which was included in 2.2 seems to be missing from 2.4.1.
The idea was taken from trident.c, and it keeps xmms at normal CPU
usage. Same patch against 2.4.1 would look like this, but it's
totally untested:
--- drivers/sound/i810_audio.c.orig Thu Jan 4 21:50:17 2001
+++ drivers/sound/i810_audio.c Mon Feb 12 17:05:48 2001
@@ -879,7 +879,9 @@
dmabuf->endcleared = 1;
}
}
- wake_up(&dmabuf->wait);
+ if (dmabuf->count < (signed)dmabuf->dmasize/2) {
+ wake_up(&dmabuf->wait);
+ }
}
}
/* error handling and process wake up for DAC */
@@ -899,7 +901,9 @@
printk("DMA overrun on send\n");
dmabuf->error++;
}
- wake_up(&dmabuf->wait);
+ if (dmabuf->count < (signed)dmabuf->dmasize/2) {
+ wake_up(&dmabuf->wait);
+ }
}
}
}
Also I'll have to ask you to please go and play some mirrormagic as
you promised when I sent the 2.2-patch. ;-)
As of 2.2.18 the sound in most games still sounds like crap on my
82443MX-100-based laptop with the i810_audio driver, while alsa works
quite nicely.
//Marcus
--
---------------------------------+---------------------------------
Marcus Sundberg | Phone: +46 707 452062
Embedded Systems Consultant | Email: [email protected]
Cendio Systems AB | http://www.cendio.com