changing audio routing through mixer controls with emu10k1/audigy

changing audio routing through mixer controls with emu10k1/audigy

[Corvus Corax]

Hello

I just switched from using the OSS emu10k1 driver to alsa.
However the mixer controls seem a bit screwed up, nothing new though, since the
default setup of the programmable emu10k1 chip IS a bit screwed.

Especially with a sourround setup its annoying to be unable to change the total
volume since both PCM and MASTER dont affect the rear and center speakers, so to
"just change the volume" you have to change 3 sliders - not to mention breaking
a the sensitive fine-tuning 

With the emu10k1 project came some tools, that made it possible to load sound
modificating applets into the DSP core and more important, change the routing of
audio signals from sources (input, PCM, ...) over a freely definable set those
filters and mixer controls towards output channels

for example like this

inputs		mixer		filter		mixer		mixer		output


PCM_l		PCM_l ctrl	global_tone	master_l	digital 1 l	front-left
PCM_r		PCM_r ctrl	global_tone	master_r	digital 1 r	front-right
PCM_l		PCM_l ctrl	global_tone	master_l	digital 2 l	rear-left
PCM_r		PCM_r ctrl	global_tone	master_r	digital 2 r	rear-right
PCM_l		PCM_l ctrl	global_tone	master_l	digital 3 l	center
PCM_r		PCM_r ctrl	global_tone	master_r	digital 3 r	sub
LINE_IN_l	LINE_l ctrl	global_tone	master_l	digital 1 l	front-left
LINE_IN_r	LINE_r ctrl	global_tone	master_r	digital 1 r	front-right
LINE_IN_l	LINE_l ctrl	global_tone	master_l	digital 2 l	rear-left
LINE_IN_r	LINE_r ctrl	global_tone	master_r	digital 2 r	rear-right
LINE_IN_l	LINE_l ctrl	global_tone	master_l	digital 3 l	centert
LINE_IN_r	LINE_r ctrl	global_tone	master_r	digital 3 r	sub
...

with this, even with the limited set of OSS mixer controls, a really usefull
control was possible - as the volume controls were nothing more than DSP
loaded filters with a driver given modifyable vcalue applied, too.
So changing the volume slider on an oss mixer made the driver to update that
value for the filter, this way it being possible to attach things like a
"cut frequency" to an OSS mixer volume control during runtime

However OSS is deprecated and I wasnt able to run the dsp-mgr coming with the
emu10k1 OSS driver project under my current kernel and architecture :-(

So my question: is a similar functionality implemented in the alsa emu10k1
driver? where are the tools to load those routes using the alsa drivers?
who is working on them? can I help developing them somehow?

regards

Corvus


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: changing audio routing through mixer controls with emu10k1/audigy

[Lee Revell]

On Sun, 2005-09-25 at 23:46 +0000, Corvus Corax wrote:
> So my question: is a similar functionality implemented in the alsa
> emu10k1
> driver? where are the tools to load those routes using the alsa
> drivers?
> who is working on them? can I help developing them somehow? 

Yes, it's called ld10k1, the GUI is qlo10k1.  It's part of alsa-utils.
It's currently in rough shape, we could certainly use some developers.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: changing audio routing through mixer controls with emu10k1/audigy

[Lee Revell]

On Sun, 2005-09-25 at 21:04 -0400, Lee Revell wrote:
> On Sun, 2005-09-25 at 23:46 +0000, Corvus Corax wrote:
> > So my question: is a similar functionality implemented in the alsa
> > emu10k1
> > driver? where are the tools to load those routes using the alsa
> > drivers?
> > who is working on them? can I help developing them somehow? 
> 
> Yes, it's called ld10k1, the GUI is qlo10k1.  It's part of alsa-utils.
> It's currently in rough shape, we could certainly use some developers.

Sorry, I mean alsa-tools, not alsa-utils.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: changing audio routing through mixer controls with emu10k1/audigy

[Corvus Corax]

Am Sun, 25 Sep 2005 21:09:42 -0400
schrieb Lee Revell <rlrevell@joe-job.com>:

> On Sun, 2005-09-25 at 21:04 -0400, Lee Revell wrote:
> > On Sun, 2005-09-25 at 23:46 +0000, Corvus Corax wrote:
> > > So my question: is a similar functionality implemented in the alsa
> > > emu10k1
> > > driver? where are the tools to load those routes using the alsa
> > > drivers?
> > > who is working on them? can I help developing them somehow? 
> > 
> > Yes, it's called ld10k1, the GUI is qlo10k1.  It's part of alsa-utils.
> > It's currently in rough shape, we could certainly use some developers.
> 
> Sorry, I mean alsa-tools, not alsa-utils.
> 
> Lee
> 

Thanks.

I tested those from 1.0.10rc1 on my system (amd64 architecture)

The tools (unlike their OSS counterparts which are segfaulting on this arch) are
compiling and working on my system, however there is either no effect on the
DSP, or garbage out of the speaker - while the front end seems to be working
( additional mixer sliders and all appear and seem to be working, however
without any effect on sound output)

Now the question, what is the current development status? are they supposed to
work correctly on sb_live hardware? if so, the problem must be architecture
related - (seems so, since the OSS drivers dont work either)

My guess on the problem of the OSS driver was some type conversions in
the kernel module going wrong - causing a different (pointer) variable in
userspace to be overwritten during an unrelated ioctl which then causes a
segfault afterwards.

However since the alsa driver works and just the backend produces garbage I dont
know exactly where to search for. Could it be that the as10k1 assemmbler
produces incorrect DSP code on amd64?

The .bin files built by the OSS as10k1 on i386 differ in a few bytes from the
one build now under x86_64 (with a as10k1 compiled for x86_64) - but then that
could be version information, too.

As I said, I would like to help development with that - is there any background
documentation on how the emu10k1 DSP is to be programmed?

regards

Corvus Corax


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: changing audio routing through mixer controls with emu10k1/audigy

[Lee Revell]

On Mon, 2005-09-26 at 22:36 +0000, Corvus Corax wrote:
> The tools (unlike their OSS counterparts which are segfaulting on this
> arch) are compiling and working on my system, however there is either
> no effect on the DSP, or garbage out of the speaker - while the front
> end seems to be working ( additional mixer sliders and all appear and
> seem to be working, however without any effect on sound output) 

Did you run the init_live script?  This should produce the same mixer
state that the driver contains by default.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: changing audio routing through mixer controls with emu10k1/audigy

[Corvus Corax]

Am Mon, 26 Sep 2005 19:43:22 -0400
schrieb Lee Revell <rlrevell@joe-job.com>:

> On Mon, 2005-09-26 at 22:36 +0000, Corvus Corax wrote:
> > The tools (unlike their OSS counterparts which are segfaulting on this
> > arch) are compiling and working on my system, however there is either
> > no effect on the DSP, or garbage out of the speaker - while the front
> > end seems to be working ( additional mixer sliders and all appear and
> > seem to be working, however without any effect on sound output) 
> 
> Did you run the init_live script?  This should produce the same mixer
> state that the driver contains by default.
> 
> Lee
> 

yes, its running "flawlessly" and the qlo10k1 program is displaying all those
quite complex routes as it should (I guess at least, they make sense that way
they are)

Only the soundcard doesnt behave like it should, regardless of loaded patch set
I get one of three outcomes:

1 no sound at all
2 sound like without any patches loaded (only 2 speakers active)
3 like two, but with more or less extreme distortion on the left speaker

those card status change randomly when I remove or add routings or patches,
so even when I remove I route totally unrelated to the PCM--....-->Speaker path
so soundcards behaviour sometimes changes - totally randomly

when I say "clear_dsp" the card works like in standard setup and no routes or
patches are displayed - I guess that function is at least working as it should.

(mentionable that the same card worked with a tuned custom patchset under OSS
 on my old linux system and the windows drivers work as expected too, so the
 DSP hardware is likely to be ok)

could it be that some of the data to be loaded into the DSP may be of
wrong type - or loaded onto a wrong address in DSP memory - doe to being run on
a 64bit system with pointers twice as big? (sizeof(int*)=8)

how could I debug this?



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl