From: Jonathan W. <jw...@ph...> - 2010-12-06 23:44:50
|
> > If an in-kernel streaming module were to come about I think it would have to > > operate at the "construct the packet" level since that is where much of the > > timing related complexity lies. Assuming this then the above statement from > > Pieter would be correct. > > Such a streamer component would have to join audio streams? into the > outbound 1394 stream and to splice the inbound 1394 stream into audio > streams?. (? and music streams, i.e. MIDI) Yes. And to do this for certain devices it needs to know what the device configuration is so it can deduce details like the number of channels to put into the packet, the number of frames a packet can have, and so on. In addition to this it would also have to have the flexibility to extract/encode non-audio/music streams since some devices make use of this. Admittedly ffado doesn't utilise these substreams yet but it's on my long term plans. I'll give a couple of concrete examples. Most MOTU devices have extensive front-panel controls which allow you to configure the entire device without the use of the PC. In the case of the onboard mixer these controls are not locked out when a PC mixer application is running. To keep everything in sync the device embeds its current mixer status as a substream in the iso data stream. The PC mixer application should monitor this and when a change is noted the relevant GUI element can be updated. Ffado doesn't do this yet because there's no pre-cooked method to get this information out of the streaming layer and into the mixer, and I've had more important tasks to do than work on one. It is however a feature I want to eventually add. My other example are the RME devices. Among other things, these devices feature hardware-calculated level meters on each channel and the values of the "meters" are sent to the PC as part of iso packets. Again it would be nice to be able to make use of these eventually since it permits true RMS/peak metering of all 56 input channels with practically no hardware load on the PC. I bring these two examples up to show that any streaming engine devised in future will need a way to deal with non-audio, non-music data: both internally and via an API of some sort. > Could the streamer component read device registers --- independently of > another agent that configures the device --- in order to collect the > necessary information itself instead of getting it from the controlling > agent? > > (I know, this sounds awkward and inefficient if it were possible at all. > But for example the IEC 61883 model works just like this: Talkers, > listeners, and controllers may be independent entities. Hardly > surprising though if there is no provision for such flexibility in a > vendor protocol.) In the case of MOTU this *may* be possible, but it would involve the streaming component (in the kernel) having to duplicate a fairly significant portion of the code used to control the device. Just from a maintenance view this doesn't seem like a good idea because suddenly we end up with two lots of code which need to be kept up to date as new devices are released and as bugs are found. For RME I'll have to think about it some more - those devices are quite a bit different in regard to configuration management than every other device we support. > > > > And vice versa, weren't there platforms which spliced configuration > > > > status information into the isochronous stream? > > > > > > Again, both the MOTU and RME protocols embed this info. > > > > Correct. > > Is this embedded information per chance additionally available in device > registers? Or is it information that is not actually required by a > controller? (To state the obvious: Otherwise, a controller > necessarily needs to be a stream listener or needs to be coupled with a > listener via a potentially rather hardware specific interface...) I eluded to some of this information above. Talking generally, some of the information is available in device registers but some is not. To revisit the two examples I gave before, the MOTU mixer status is readable via registers but requiring a PC mixer application to poll device registers to spot changes isn't going to be all that efficient. In the case of the RME level data this is not available from registers (it would make no sense to do so since it changes too frequently). Regards jonathan |