linuxaudio.org

Thanks, Fernando.  I'll scan the devel lists for this discussion.
I would assume that this change of # of channels (visible with

HDSPmixer) would only mandate that the range/speed not be changed

while in operation.  This might even mean shutting down JACK or other

clients at times, etc.  Totally understandable.
However it should be able to change rates when a file at a new rate is

played or when JACK requests a new rate.  I can force it to work now

just by adding an alias for all apps which scans the soundfilefile

header and sends the appropriate "amixer numid=11" switch before

playing or opening the file.  I assume ALSA can do something similar

on its own (?).
I'm sure I oversimplifying ;)
Kevin
On 23 Dec 2004 21:53:34 -0800, Fernando Lopez-Lezcano

 wrote:

quoted text
> On Thu, 2004-12-23 at 20:11, Kevin Ernste wrote:

> > > Range 1 - 44.1K/48K

> > > Range 2) 88.2K/96K

> > >

> > > Jack can switch between either rate in each range, but for whatever

> > > reason it cannot switch between the two ranges themselves.

> >

> > Aha, this is precicely the behaviour I was looking for _across_ the

> > two ranges!  As you say, sampling rates change happily within each

> > range, just not to/from rates in the other.  In any case, I'm relieved

> > to know that it's not my setup (things are working remarkably well

> > now).

> >

> > I may contact the developer (if only to thank him) and inquire about

> > this, it seems to me that ALSA or JACK should be able to inform

> > HDSPconf of a rate change regardless of speed/range.  It is

> > particularily painful at the command line where I'm jumping back and

> > forth between rates all the time meaning HDSPconf is always open ;)

>

> There was a thread long ago about this. I think the issue is that the

> number of channels that the device supports change with the switch

> between the two ranges of sampling rates. I don't remember why this was

> a problem.

>

> -- Fernando

>

>