Re: hdspmixer broken for 96khz

[Tim Blechmann <tim@klingt.org>]

> I wonder what went wrong. If you like, feel free to further dig into
> this.
> 
> However, the current on-disk format is utterly stupid, it has no
> meta-information at all, it will break if the order of cards change.
> 
> The whole hdspmixer is a dead-end, even supporting more than one card in
> a single app complicates things like hell (I have an upcoming patch
> series. Took me 6hrs or so just to get switching back/forth between two
> cards right).

the hdspmixer is not perfect, but it more or less worked for years and it is 
used in `production' environments. so breaking the parts that are currently 
working is quite annoying for users.

> So the next thing I'd like to implement is to limit hdspmixer to a
> single card and then run a new instance on the second, third, 4th a.s.o.
> card. Like alsamixer -c 1: hdspmixer -c 1, maybe -c reflecting the ALSA
> card number as found in /proc/asound/cards.
> 
> Anyway, the whole codebase is subtle broken, and the best approach would
> be a rewrite from scratch. Maybe it makes sense to merge hdsp and hdspm,
> first. Comments welcome. ;)

rewriting the hdspmixer doesn't sound like a bad idea to me. reworking the 
sampling rate switching would be a great help as well: the hdsp is the only 
device i know, which requires an external program to switch the sampling rate. a 
few years ago i had a brief look at the driver, but this seemed to be a non-
trivial problem.

cheers, tim

-- 
tim@klingt.org
http://tim.klingt.org

Most of the trouble in this world has been caused by folks who can't
mind their own business, because they have no business of their own to
mind, any more than a smallpox virus has.
  William S. Burroughs