Thanks, this is good news. Could you also please test hdspmixer with the expansion board and confirm there's no problem here either ?
Yes, hdspmixer does all the right things with the extra channels.
Good news too.
There appears to be a minor bug in that the input channels 8 and 9 (I think?), ie the top right two inputs (right of the spdif input), do not draw properly initially. The numbers, and bits of the outline appear, but the sliders and bars don't draw. At some later stage it all appears properly.
Thanks for the report, I'll check this.
Since this is done using a remote xsession to a windows PC and cygwin I can't be sure that this isn't just an X problem on win32... It's a minor issue anyway
Actually more of an issue is that there is a ton of X traffic when stuff is playing which overwhelms my 802.11a network. PC gets maxed out with a high cpu load just trying to squirt all the traffic over SSH. I wonder if we could have variable refresh rates on the bouncing level meters? Or perhaps you could investigate whether less of the screen could be updated perhaps (optimised drawing of boxes might reduce X traffic?)
It is already supposed to be optimized to minimize redraws (but it's been a long time since I last worked on this part of the code, maybe it could be optimized further). Anyway redraws are indeed frequent. I have to say that my primary concern was cpu load with this. One plan I have for the future is to use OpenGL to reduce this load, but it'll be no help in your case.
This would just be a workaround, but maybe you could try tunneling VNC instead of X through SSH. You'll get de facto a smaller refresh rate and a reduced bandwidth consumption.
Anyway, just a nice to have. Thanks for what we have already though!
Just to make it clear that this is a software problem and not the problem that Tim, Paul and Mark reported, could you please try to route an incoming signal (through analog or digital in) to your amp using hdspmixer and tell me if the routed sound suffers from the same audio corruption as the one being played back ? (this test should be done while you're playing back a stuttering software stream)
Sure, will do. For what it's worth the same film works under xine, but not mplayer.
Alsaplayer also works fine I think (on different files), as does aplay. I would be pretty sure that for a given FLAC file, alsaplayer would play it fine and mplayer would stutter.
I will try and grab the mplayer source and have a peer at the audio output code.
It sounds like an application design issue, then.
I think the nicest feature you'd get with this design is the ability to manipulate totalmix/hdspmixer's enhanced mixer (with this output stage) from several applications in a coherent way (hdspmixer, ladpsa plugin, script, midi automation, etc...), a feature that people constantly ask for on the RME forum. This could also very well "sell" a few linux installs to RME customers :)
Please consider dropping me a line if you do any work on this. I would love to test it as you go along.
Sure, no problem.
Thanks, Thomas
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
