Re: [linux-audio-dev] emu10k1 multichannel support

I posted this to alsa-devel but since my previous post on this list generated a lot of interest, I am just reposting it here. As promised, here's an updated patch to add real multichannel playback support (and improved multichannel capture) to the emu10k1 driver. http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v001.patch Please test it and report any problems. I am especially interested in any regressions that impact regular PCM playback (the hw:0,0 device). QuickStart: $ jackd -R -v -d alsa -P hw:0,3 -C hw:0,2 -S I tested this and it works well with 16in/16out at 128, 256, 512 frames. 32 and 64 should work too but I can't test as I'm running a stock 2.6.10 kernel for now ;-). You can check that the routing is correct by connecting a JACK client to the playback ports corresponding to the FX buses described in Documentation/Audigy-mixer.txt and Documentation/SB-Live-mixer.txt, and verifying that the output appears on that channel (the FX buses are numbered from 0 but JACK numbers clients from 1). For example (from SB-Live-mixer.txt): name='Music Playback Volume',index=0 This control is used to attenuate samples for left and right MIDI FX-bus accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples. The result samples are forwarded to the front DAC PCM slots of the AC97 codec. So "alsaplayer -o jack -d alsa_pcm:playback_5,alsa_pcm:playback_6" should output to FX buses 4 and 5, which you can test by lowering the 'Music' control in alsamixer. With an SBLive, use ports 1 and 2 for the front channels, 3 and 4 for the rear channels. The Audigy uses different channels, see the above docs for more info. In addition to multichannel recording applications, this should also be useful for OpenAL implementations, which are currently restricted to using 21 sources due to the use of an extra voice per stereo PCM. This should allow up to 63 sources. This also adds some new register info including a per channel half loop interrupt that I have discovered by reverse engineering the Windows drivers. Improvements over previous versions: - Routes the 16 channels to the 16 FX buses by default. - Enables the first 16 FX capture outputs by default, required for full duplex operation at latencies lower than 512 frames. - Rewrote the voice allocator to use a more efficient round robin algorithm, eliminating the need to reserve the first 16 voices for the multichannel device. The next free voice is maintained in the card record and the search starts from there. - Use an extra voice for playback timing rather than the EFX capture interrupt. I was only ever able to get that to work at 64 frames. Also there are definite advantages to being able to use the capture and playback devices independently. - Use the newly discovered per-channel half loop interrupt source for the extra voice rather than the channel loop interrupts. For unknown reasons, this works better for multichannel playback, and does not seem to affect regular PCM playback at all. TODO: - Fix the send routing and volume controls for the multichannel device. The current (copy and paste) solution assumes either one or two voices per PCM. So the default settings work fine but changing them with the mixer is likely to have unpredictable effects. - EFX capture should capture output channels 16-32 (mostly unused now) by default, so that we only capture the sources the user has connected to the multichannel recording inputs in the DSP manager. Typically FX buses 0-15 would be connected directly to FX outputs 16-32 so the capture channels would correspond directly to the playback channels. In order for this to work the default DSP configuration has to be changed slightly. Lee