Re: HDSP 9632 driver and expansion cards

[Thomas Charbonnel <thomas@undata.org>]

Ed Wildgoose wrote :
>>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