Short story:

I'd like to get hold of the kernel module parameters (and any documentation I 
can get) for the cx5530 sound driver module. Seems someone added it to LTSP 
4.1... Problem is: OpenOSS' cs5530 mentions a geode_poll_mode that I would 
really like to set, but the one in LTSP doesn't have that parameter. Does it 
have something corresponding? Or something corresponding to sb's "mpu_io=0"? 
I see references to National Semiconductor's site in the linux kernel dev 
list, but I can't find it there.

Long story:

Trying to get audio working on Compaq EVO T20 (natsemi geode platform).

Both video and audio can be run in native or emulation mode (vesa and sb16 for 
emulation). Running both in emulation mode works fine, but is suboptimal 
(native video is faster and gives a full refresh rate). I could live with 
native video and emulated audio, but that has big problems (a one-line patch 
was needed for nsc video, it is in latest xorg so I guess you'll get it 
eventually).

I haven't suceeeded getting cx5530 to work. It will play the first 200 ms 
(ca.) sent to /dev/dsp and then stop accepting data. sb16 emulation works 
with the sb driver and mpu_io=0 parameter. The kahlua driver works if sb has 
been loaded and then unloaded, but it does exactly the same as the sb driver 
(at least when it comes to the problems described below). The durango driver 
complains that it is the wrong kernel version...

The sb driver without the mpu_io actually has the same symptoms as cs5530 (if 
I remember correctly). Interesting.

The problem is that the nsc X driver collides with the sb audio driver. The 
first indication of the problem is visual: When playing sound, a vertical 
stripe of garbage appear in X (perhaps 30 pixels wide near the right of the 
screen, 1024x768 res btw). Making X redraw the area makes the garbage 
disappear.

The other indications are in the sound. First of all it often stutters when X 
is doing something (though not all the time). Secondly:

X changes the PCM volume of the mixer.

Yes, seriously! Seems like X is writing to memory it shouldn't be writing 
to... First thing I noticed is that switching between a maximized and regular 
window, volume would jump between perhaps 80 and 100 (with a lower volume 
when the regular window was open). When changing the main volume with 
aumix-minimal the same behaviour would occur at a lower overall volume, 
however when changing the pcm volume it would soon be overwritten by X...

Changing to Mozilla Firefox would completely halt the sound... switching tabs 
makes it come back, and sometimes moving the mouse can also make it come 
back. Note that firefox couldn't possibly know about the mixer, as it is 
running on the server and all tests were done through running bplay with a 
wav-file locally on the client - they are physically seperated.

So now I'd just like to try the non-emulated audio driver and see what 
happens...

// Dag Sverre



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to