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