[alsa-devel] Patch - Revo7.1 PCM Playback Switch
Hello Takashi,
I have attached a patch to support mute for front channels of M-Audio Revolution 7.1 (the DAC AK4381 features a mute bit).
Signed-off-by: Pavel Hofman <dustin at seznam.cz>
Please could I ask you for your opinion on the following issue (so far no response):
I am working together with Ctirad on supporting more capture channels in E-MU1212. So far we have managed to increase the number of channels from the default of 8 to 16 (A_FXWC2 = 0xffffffff, added new snd_emu10k1_audigy_dsp_convert_32_to_2x16 calls in emufx.c). There is still a number of issues to solve but the 16 channel capture already works fine.
I would like to get your opinion on the form of adding this support to the module. The options are either hard-coding the 16 capture channels into the code, assuming that users would prefer as many channels as possible and do the routing in jack, or introducing a module parameter emu1010-capture-channels (range e.g. 1 to 16 - untested yet) and leaving the default number at the existing 8.
Furthermore, the PCMs other than efx seem to be of no use for the EMU-1x1x models, probably fairly confusing for new users. Would you find it OK, if they were removed for this specific card (if (emu->card_capabilities->emu1010)), keeping only the playback and capture PCM id 2?
Thanks a lot for your suggestions. Based on them, I will prepare the patch (with comments on what we found out about the card - it is a pitty that the driver has almost no big-picture comments on the supported cards' specifics, making new developers spend a number of long nights going through the nontrivial code and guessing).
Best regards,
Pavel.
On 5/18/07, dustin@seznam.cz dustin@seznam.cz wrote:
I would like to get your opinion on the form of adding this support to the module. The options are either hard-coding the 16 capture channels into the code, assuming that users would prefer as many channels as possible and do the routing in jack, or introducing a module parameter emu1010-capture-channels (range e.g. 1 to 16 - untested yet) and leaving the default number at the existing 8.
I think you should hard code 16 channels. If this device works anything like the emu10k1, then you can achieve lower latency by capturing more channels (because the capture buffer limits are in bytes, so more channels = fill an N byte buffer faster = lower latency).
This is how I did multichannel support for the emu10k1 and it works great, no one has ever complained about wanting to capture fewer channels...
Lee
At Fri, 18 May 2007 22:53:50 +0200 (CEST), dustin@seznam.cz wrote:
Hello Takashi,
I have attached a patch to support mute for front channels of M-Audio Revolution 7.1 (the DAC AK4381 features a mute bit).
Signed-off-by: Pavel Hofman <dustin at seznam.cz>
Applied to HG tree. Thanks.
Please could I ask you for your opinion on the following issue (so far no response):
I am working together with Ctirad on supporting more capture channels in E-MU1212. So far we have managed to increase the number of channels from the default of 8 to 16 (A_FXWC2 = 0xffffffff, added new snd_emu10k1_audigy_dsp_convert_32_to_2x16 calls in emufx.c). There is still a number of issues to solve but the 16 channel capture already works fine.
I would like to get your opinion on the form of adding this support to the module. The options are either hard-coding the 16 capture channels into the code, assuming that users would prefer as many channels as possible and do the routing in jack, or introducing a module parameter emu1010-capture-channels (range e.g. 1 to 16 - untested yet) and leaving the default number at the existing 8.
I'm for the fixed number 16, as Lee already suggested. It's simpler, and no one would complain that he has too many :)
Furthermore, the PCMs other than efx seem to be of no use for the EMU-1x1x models, probably fairly confusing for new users. Would you find it OK, if they were removed for this specific card (if (emu->card_capabilities->emu1010)), keeping only the playback and capture PCM id 2?
I think it's OK to remove them if they are really useless. But, make sure to change the card->driver name if you do this. Otherwise the same configuration as Audigy2 or whatever will be used and it may result in accessing non-existing devices.
Thanks a lot for your suggestions. Based on them, I will prepare the patch (with comments on what we found out about the card - it is a pitty that the driver has almost no big-picture comments on the supported cards' specifics, making new developers spend a number of long nights going through the nontrivial code and guessing).
The patches will be definitely appreciated.
thanks,
Takashi
Hello,
Here is the patch increasing number of capture channels from 8 to 16. In this patch the unused PCMs are not removed yet, I have not been able to test thoroughly to confirm they are 100% sure useless.
As a next project, I would like to try to raise playback resolution from the current 16bits to 24 (32) bits, using audigy DSP instructions, inversion of the convert32to2x16 function. I would really appreciate comments and suggestions from experts on this card regarding feasibility and possible caveats.
Patch description:
* adding 8 more 32-bit capture channels (total of 16) for emu1010 cards * adding some code comments and card details description
Signed-off-by: Pavel Hofman dustin@seznam.cz
Thans a lot,
Pavel.
I am working together with Ctirad on supporting more capture channels in E-MU1212. So far we have managed to increase the number of channels from the default of 8 to 16 (A_FXWC2 = 0xffffffff, added new snd_emu10k1_audigy_dsp_convert_32_to_2x16 calls in emufx.c). There is still a number of issues to solve but the 16 channel capture already works fine.
I would like to get your opinion on the form of adding this support to the module. The options are either hard-coding the 16 capture channels into the code, assuming that users would prefer as many channels as possible and do the routing in jack, or introducing a module parameter emu1010-capture-channels (range e.g. 1 to 16 - untested yet) and leaving the default number at the existing 8.
I'm for the fixed number 16, as Lee already suggested. It's simpler, and no one would complain that he has too many :)
Furthermore, the PCMs other than efx seem to be of no use for the EMU-1x1x models, probably fairly confusing for new users. Would you find it OK, if they were removed for this specific card (if (emu->card_capabilities->emu1010)), keeping only the playback and capture PCM id 2?
I think it's OK to remove them if they are really useless. But, make sure to change the card->driver name if you do this. Otherwise the same configuration as Audigy2 or whatever will be used and it may result in accessing non-existing devices.
Thanks a lot for your suggestions. Based on them, I will prepare the patch (with comments on what we found out about the card - it is a pitty that the driver has almost no big-picture comments on the supported cards' specifics, making new developers spend a number of long nights going through the nontrivial code and guessing).
The patches will be definitely appreciated.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Thu, 31 May 2007 23:10:22 +0200 (CEST), dustin@seznam.cz wrote:
Hello,
Here is the patch increasing number of capture channels from 8 to 16. In this patch the unused PCMs are not removed yet, I have not been able to test thoroughly to confirm they are 100% sure useless.
As a next project, I would like to try to raise playback resolution from the current 16bits to 24 (32) bits, using audigy DSP instructions, inversion of the convert32to2x16 function. I would really appreciate comments and suggestions from experts on this card regarding feasibility and possible caveats.
Patch description:
- adding 8 more 32-bit capture channels (total of 16) for emu1010 cards
- adding some code comments and card details description
Signed-off-by: Pavel Hofman dustin@seznam.cz
Thanks for the patch. The changes appear OK (as I have no hardware for testing), but please try to follow the standard coding style. Namely,
- don't put space after '(' - keep 80 chars in a line (including comments) fold lines appropriately - don't put braces { } for a single if-else command
Anyway, the patch will be merged after 1.0.14, so don't worry about the delay :)
Takashi
Takashi,
Thanks a lot, and sorry for the coding style.
Pavel.
------------ Původní zpráva ------------ Od: Takashi Iwai tiwai@suse.de Předmět: Re: EMU 1212 - 16 capture channels - patch Datum: 04.6.2007 15:05:46
At Thu, 31 May 2007 23:10:22 +0200 (CEST), dustin@seznam.cz wrote:
Hello,
Here is the patch increasing number of capture channels from 8 to 16. In this
patch the unused PCMs are not removed yet, I have not been able to test thoroughly to confirm they are 100% sure useless.
As a next project, I would like to try to raise playback resolution from the
current 16bits to 24 (32) bits, using audigy DSP instructions, inversion of the convert32to2x16 function. I would really appreciate comments and suggestions from experts on this card regarding feasibility and possible caveats.
Patch description:
- adding 8 more 32-bit capture channels (total of 16) for emu1010 cards
- adding some code comments and card details description
Signed-off-by: Pavel Hofman dustin@seznam.cz
Thanks for the patch. The changes appear OK (as I have no hardware for testing), but please try to follow the standard coding style. Namely,
- don't put space after '('
- keep 80 chars in a line (including comments) fold lines appropriately
- don't put braces { } for a single if-else command
Anyway, the patch will be merged after 1.0.14, so don't worry about the delay :)
Takashi
At Thu, 07 Jun 2007 11:08:22 +0200 (CEST), dustin@seznam.cz wrote:
Takashi,
Thanks a lot, and sorry for the coding style.
Don't worry. I fixed it and now committed your patch to HG tree.
Thanks.
Takashi
Takashi Iwai wrote:
At Thu, 07 Jun 2007 11:08:22 +0200 (CEST), dustin@seznam.cz wrote:
Takashi,
Thanks a lot, and sorry for the coding style.
Don't worry. I fixed it and now committed your patch to HG tree.
Thanks.
Takashi
I have just had a chance to look at the patch. It looks ok to me too, although I have not had a chance to test it. I have rather a lot of patches in my inbox, hopefully I will get through them soon.
James
participants (4)
-
dustin＠seznam.cz -
James Courtier-Dutton -
Lee Revell -
Takashi Iwai