[alsa-devel] Fast Track Ultra mixer - opinions anyone?
Hi,
over the weekend I tried to prepare a "set-everything-to-zero-by-default" mixer patch. And failed... I could get the controls to be defaulted to zero by quirking the volume range, but then there would not have been any sound at all, even after adjusting the levels.
So without diving any deeper in this I decided to put some work in the mixer controls. You can find a patch to play with attached to this mail. I've left a couple of commented quirks in mixer.c so you can see, where simple changes can be made.
But working on this patch raised a couple of questions I would like hear your opinions on:
** Effects **
Essentially, with the attached patch you can control everything but the effect program. The switch should not be too hard to implement. But before I put any more work on it I would like to ask wether it makes sense at all.
IMO, the effect section on the FTUs really sucks. I can't believe that anybody can really use it in a reasonable way. So should we really add another 40 controls to the mixer which can cause a lot of pain when misadjusted (i.e. anything else but 0)?
For those reasons I would prefer not to put effect support in the kernel. What do you think?
** dB values **
Currently alsamixer does not report any dB changes when you change a control value. I don't know how to fix it. Anyone else?
** Naming scheme again **
Once again, is everyone pleased with the current naming scheme?
Looking forward for your suggestions.
Regards,
Felix
** Effects **
Essentially, with the attached patch you can control everything but the effect program. The switch should not be too hard to implement. But before I put any more work on it I would like to ask wether it makes sense at all.
IMO, the effect section on the FTUs really sucks. I can't believe that anybody can really use it in a reasonable way. So should we really add another 40 controls to the mixer which can cause a lot of pain when misadjusted (i.e. anything else but 0)?
For those reasons I would prefer not to put effect support in the kernel. What do you think?
What if they are activated somehow, and a user would loke to turn them off?
You're completely right, the effects on this soundcard are useless, but let say they have been turn on in a Windows session, would the FTU turn them back off at reboot, or would they still be on?
** Naming scheme again **
Once again, is everyone pleased with the current naming scheme?
The naming scheme is indeed very confusing, but what other solution is there? I used the FTU mixer under Windows and it is as confusing :) I'm not sure the problem is with the naming convention though, but more what the Alsa mixers look like... Gamix used to be perfect for the FTU with all the controls in a grid, it was very clear how the levels were setup... Unfortunately it's not maintained anymore, even in Ubuntu...
So that's my 2 cents...
Aurélien
On Mon, Apr 16, 2012 at 8:38 PM, Felix Homann linuxaudio@showlabor.dewrote:
re-sending to everyone...
[SNIP]
** Effects **
Essentially, with the attached patch you can control everything but the effect program. The switch should not be too hard to implement. But before I put any more work on it I would like to ask wether it makes sense at all.
IMO, the effect section on the FTUs really sucks. I can't believe that anybody can really use it in a reasonable way. So should we really add another 40 controls to the mixer which can cause a lot of pain when misadjusted (i.e. anything else but 0)?
For those reasons I would prefer not to put effect support in the kernel. What do you think?
Nope it absolutely should be supported to fully support the device.
They're for monitoring if used as intended... ie: when doing hardware based monitoring.
** dB values **
Currently alsamixer does not report any dB changes when you change a control value. I don't know how to fix it. Anyone else?
What does dB value mean in this context given there's a hardware volume knob on the device? is it just the db difference or is supposed to be some sort of dBm absolute output level
the specs say that the output at the rear of the device is +10 dBm balanced and +1.8dBu unbalanced
and the headphones are 0dBm into 32 ohms
** Naming scheme again **
Once again, is everyone pleased with the current naming scheme?
I think it's ok. I still think we need some better tools. but with 16*8
controls now and another 4x8 for effects + effect select and misc controls like clock select I think some better ui is necessary.
2012/4/16 Grant Diffey gdiffey@gmail.com:
** dB values **
Currently alsamixer does not report any dB changes when you change a control value. I don't know how to fix it. Anyone else?
What does dB value mean in this context given there's a hardware volume knob on the device? is it just the db difference or is supposed to be some sort of dBm absolute output level
What I meant was: At the moment we can just change raw control values without knowing what they mean. E.g. if we put some control value to 50% do we get linear gain of 50% . Do we have a logarithmic scale or a "M-Audio-we-work-on-standards-but-dont-support-them" scale?
Felix Homann wrote:
IMO, the effect section on the FTUs really sucks. I can't believe that anybody can really use it in a reasonable way. So should we really add another 40 controls to the mixer which can cause a lot of pain when misadjusted (i.e. anything else but 0)?
For those reasons I would prefer not to put effect support in the kernel. What do you think?
If you want to be able to use these effects at all, there must be _some_ way to access the controls.
Generic mixer programs like alsamixer are not really suitable for complex devices; you'd need to write a custom mixer.
If you want to prevent the controls from showing up in alsamixer, set their .iface to SNDRV_CTL_ELEM_IFACE_CARD instead of _MIXER. (But if these controls don't show up in alsamixer, you wouldn't be able to reset them if they are misadjusted ...)
Currently alsamixer does not report any dB changes when you change a control value.
Set the TLV. For standard controls, the code reads the values from the USB descriptors, but for control you create by hand, you have to create these, too.
Regards, Clemens
OK,
I think I've got the mixer essentially done.
* Added Effect section including effect program switch * Added TLV (dB gain information -> makes huge improvement in usability)
Could you please try the attached patch and give some feedback before I submit it.
I've already noticed that KMix will crash trying to control the FTU. It will take the whole KDE session down, too. But since neither alsamixer, amixer nor qasmixer show similar behaviour I guess it's an issue within KMix (too many controls?) - not one of the patch...hopefully.
Regards,
Felix
Here's a slightly modified patch to test.
It properly (hopefully) frees some memory if things go wrong. And I cleaned up some comments etc.
It's against alsa-kmirror so you can test it without recompiling the whole kernel
(Like this: git clone git://git.alsa-project.org/alsa-driver.git alsa-driver git clone git://git.alsa-project.org/alsa-kmirror.git alsa-kmirror
[patch alsa kmirror...]
cd alsa-driver ./gitcompile --with-oss=no --with-pcm-oss-plugins=no --with-debug=full --enable-dynamic-minors --with-moddir=updates sudo make install sudo alsa force-reload
when rebuilding after applying a patch just do
make sudo make install alsa force-reload )
Regards,
Felix
2012/4/18 Felix Homann linuxaudio@showlabor.de:
Here's a slightly modified patch to test.
Sorry, here it *really* is.
participants (4)
-
Aurélien Leblond -
Clemens Ladisch -
Felix Homann -
Grant Diffey