[alsa-devel] caiaq driver: audio 4 dj and jackd
Is it possible to make all 4 ins/outs in the Audio 4 DJ available through the first substream device?
A user was having trouble using the NI Audio 4 DJ device with jackd. When jack connected, this 4-in/4-out device would appear as 2-in/2-out. This was the result of the fact that the channels are split up into stereo substreams. I.e. the first two channels are found in hw:x,0,0 and the last two channels are in hw:x,0,1.
The work-around was to use the `multi' plug-in to make these 2 PCM's appear as a single PCM.
There's several situations where this is a Good Thing, because it makes it easy for the user to treat the streams independently.
BUT... in the pro-audio case this is not a good thing at all.
Ideally, substream 0 would support 1, 2, or 4 channels (for both playback and capture). When substream 0 is using more than 2 channels, then substream 1 would return EBUSY when in use.
So... would it be possible to do this in the caiaq driver?
-gabriel
On Sun, Dec 01, 2013 at 07:02:27PM -0800, Gabriel M. Beddingfield wrote:
A user was having trouble using the NI Audio 4 DJ device with jackd. When jack connected, this 4-in/4-out device would appear as 2-in/2-out. This was the result of the fact that the channels are split up into stereo substreams. I.e. the first two channels are found in hw:x,0,0 and the last two channels are in hw:x,0,1.
That's right, but I don't see a problem with that. Why was jack having trouble using the two interfaces? After all, the streams are guaranteed to be synchronous, as they share the same clock in hardware.
The work-around was to use the `multi' plug-in to make these 2 PCM's appear as a single PCM.
Yes, that's the other possibility.
Ideally, substream 0 would support 1, 2, or 4 channels (for both playback and capture). When substream 0 is using more than 2 channels, then substream 1 would return EBUSY when in use.
So... would it be possible to do this in the caiaq driver?
Technically yes, but changing that would mean breakage for all other users, and making it configurable would result in yet another moving part which makes things even more complex.
Thanks, Daniel
On 12/02/2013 01:59 AM, Daniel Mack wrote:
split up into stereo substreams. I.e. the first two channels are found in hw:x,0,0 and the last two channels are in hw:x,0,1.
That's right, but I don't see a problem with that. Why was jack having trouble using the two interfaces?
Jack has always opened only one PCM device... which is the Right Thing for most recording sound cards (e.g. ice1712, hammerfall, etc.). This is the first "pro-sumer" device I've ever seen with multiple substream devices.
After all, the streams are guaranteed to be synchronous, as they share the same clock in hardware.
TBH, the whole substream concept is lost on me. Where does this guarantee come from? From the substream concept or from intimate knowledge of this device? (I.e. how would JACK know about the clock guarantee?)
...and is the the substream concept (in ALSA) trying to solve?
Ideally, substream 0 would support 1, 2, or 4 channels (for both playback and capture). When substream 0 is using more than 2 channels, then substream 1 would return EBUSY when in use.
So... would it be possible to do this in the caiaq driver?
Technically yes, but changing that would mean breakage for all other users, and making it configurable would result in yet another moving part which makes things even more complex.
How would this cause breakage? Users that use 2 stereo substreams could still work normally.
But, FULL ACK on the moving parts. That would indeed make the driver a little gross on the inside.
-gabe
On 12/02/2013 04:15 PM, Gabriel M. Beddingfield wrote:
On 12/02/2013 01:59 AM, Daniel Mack wrote:
Jack has always opened only one PCM device... which is the Right Thing for most recording sound cards (e.g. ice1712, hammerfall, etc.). This is the first "pro-sumer" device I've ever seen with multiple substream devices.
I was also uncertain when I wrote the driver which way is better. But given that there are ways in ALSA to synchronously start separate streams, I eventually went the stereo pairs way.
After all, the streams are guaranteed to be synchronous, as they share the same clock in hardware.
TBH, the whole substream concept is lost on me. Where does this guarantee come from? From the substream concept or from intimate knowledge of this device?
Both :)
(I.e. how would JACK know about the clock guarantee?)
snd_pcm_info_get_sync() should return the same clock id for both interfaces in that case. But I must admit I haven't tried this in awhile.
Technically yes, but changing that would mean breakage for all other users, and making it configurable would result in yet another moving part which makes things even more complex.
How would this cause breakage? Users that use 2 stereo substreams could still work normally.
Yes, unless you opened the first subdevice with more than 2 channels. Then an existing user for the second stream breaks. IOW: the possible configuration and usage for subdevice 1 changes depending on that of subdevice 0.
But, FULL ACK on the moving parts. That would indeed make the driver a little gross on the inside.
What are your results with the multi plugin? Is that something you can live with?
Daniel
On 12/02/2013 08:00 AM, Daniel Mack wrote:
TBH, the whole substream concept is lost on me. Where does this guarantee come from? From the substream concept or from intimate knowledge of this device?
Both :)
(I.e. how would JACK know about the clock guarantee?)
snd_pcm_info_get_sync() should return the same clock id for both interfaces in that case. But I must admit I haven't tried this in awhile.
Thanks! I'll have to play around with that.
But, FULL ACK on the moving parts. That would indeed make the driver a little gross on the inside.
What are your results with the multi plugin? Is that something you can live with?
I don't actually have one of these devices and the end-user I was helping is happy now, AFAIK.
But solving this required editing asoundrc files (ugh) and casting several magic spells. Would be nice if it "just works."
Anyway, perhaps the solution is to get JACK to recognize the extra substreams.
-gabriel
On Monday 02 December 2013 16:14, Gabriel M. Beddingfield wrote:
On 12/02/2013 08:00 AM, Daniel Mack wrote:
TBH, the whole substream concept is lost on me. Where does this guarantee come from? From the substream concept or from intimate knowledge of this device?
Both :)
<snip>
What are your results with the multi plugin? Is that something you can live with?
I don't actually have one of these devices and the end-user I was helping is happy now, AFAIK.
But solving this required editing asoundrc files (ugh) and casting several magic spells. Would be nice if it "just works."
The same problem occurs with Portaudio on this device (or similar) - it would be great to just be able to open one device with 4 channels, or 2 stereo pairs.
I had wondered whether it could be done by some card-specific definitions in eg /usr/share/alsa/cards as is done particularly with PCI cards?? Anybody any ideas?
Gabriel, could you post the multi pcm you worked out for this, as it may help others?
Regards
Alan
On 12/02/2013 11:48 AM, Alan Horstmann wrote:
But solving this required editing asoundrc files (ugh) and casting several magic spells. Would be nice if it "just works."
The same problem occurs with Portaudio on this device (or similar) - it would be great to just be able to open one device with 4 channels, or 2 stereo pairs.
I had wondered whether it could be done by some card-specific definitions in eg /usr/share/alsa/cards as is done particularly with PCI cards?? Anybody any ideas?
Good idea.
Gabriel, could you post the multi pcm you worked out for this, as it may help others?
I can't take credit for figuring it out. Got it from here:
http://ywwg.com/wordpress/?p=772
-gabe
On 12/02/2013 08:00 AM, Daniel Mack wrote:
Technically yes, but changing that would mean breakage for all other users, and making it configurable would result in yet another moving part which makes things even more complex.
How would this cause breakage? Users that use 2 stereo substreams could still work normally.
Yes, unless you opened the first subdevice with more than 2 channels. Then an existing user for the second stream breaks. IOW: the possible configuration and usage for subdevice 1 changes depending on that of subdevice 0.
Suppose a 2nd PCM device is added that would allow 1-4 channel playback/capture (call it "Multichannel Audio" or something). This pcm1 would be mutually exclusive with pcm0 (I.e. while one is open you can't use the other).
Existing applications using hw:n,0,0 and hw:n,0,1 see the exact same interface/behavior. The only failure mode is if the multichannel PCM is in use.
Applications using multichannel work-flows would use hw:n,1.
While it's not a "just works" solution -- directing users to hw:n,1 is a whole lot better than teaching them how to set up a multi plugin.
-gabe
Hi Daniel,
On 12/04/2013 08:11 PM, Gabriel M. Beddingfield wrote:
On 12/02/2013 08:00 AM, Daniel Mack wrote: Suppose a 2nd PCM device is added that would allow 1-4 channel playback/capture (call it "Multichannel Audio" or something). This pcm1 would be mutually exclusive with pcm0 (I.e. while one is open you can't use the other).
Existing applications using hw:n,0,0 and hw:n,0,1 see the exact same interface/behavior. The only failure mode is if the multichannel PCM is in use.
Applications using multichannel work-flows would use hw:n,1.
While it's not a "just works" solution -- directing users to hw:n,1 is a whole lot better than teaching them how to set up a multi plugin.
I'm considering buying one of these Audio 4 DJ devices to make this change. Would you be willing to take a change like this?
Thanks, Gabe
Hi Gabe,
On 12/10/2013 03:27 AM, Gabriel M. Beddingfield wrote:
On 12/04/2013 08:11 PM, Gabriel M. Beddingfield wrote:
On 12/02/2013 08:00 AM, Daniel Mack wrote: Suppose a 2nd PCM device is added that would allow 1-4 channel playback/capture (call it "Multichannel Audio" or something). This pcm1 would be mutually exclusive with pcm0 (I.e. while one is open you can't use the other).
Existing applications using hw:n,0,0 and hw:n,0,1 see the exact same interface/behavior. The only failure mode is if the multichannel PCM is in use.
Applications using multichannel work-flows would use hw:n,1.
While it's not a "just works" solution -- directing users to hw:n,1 is a whole lot better than teaching them how to set up a multi plugin.
I'm considering buying one of these Audio 4 DJ devices to make this change. Would you be willing to take a change like this?
Well, yes. The longer I think about it, the more I believe it would be worth a try how such a modified driver behaves.
I might do it myself, but it'll take a while until I can start working on it. If you are willing to help, I'd happily test a patch :)
Daniel
participants (3)
-
Alan Horstmann -
Daniel Mack -
Gabriel M. Beddingfield