On Tue, 2011-09-13 at 20:23 +0300, Tanu Kaskinen wrote: > On Tue, 2011-09-13 at 17:20 +0200, David Henningsson wrote: > > Any reason you would prefer "fmradio" over just "radio"? > > The use case that I have in mind is an application that wants to capture > FM radio. The application has an interface for tuning the station. The > application probably doesn't want to capture from an AM radio or an > internet radio source, because that's not what it's made for - the > tuning interface doesn't make any sense in that case. Actually, even "fmradio" is not always specific enough... I don't think media role is the right mechanism for routing FM radio streams after all. The problem is that there may be multiple tuners in the system, and the application will want to receive the audio from the right source. When creating a capture stream, the application should be able to somehow specify from which device the audio should be recorded. The first idea might be to just use the source name. But how is the application supposed to know which source is the right one? One solution would be to add some property to the FM radio source saying that "this is the source for the V4L device /dev/radio5". The application would then have to get a list of all sources and inspect their property lists. I would not choose this solution for two reasons: 1) extra work for the application and 2) the routing policy can't choose to use a filter source instead of the raw alsa source. I think the application should be able to say "I want to record from the /dev/radio5 tuner source" and still leave the dev parameter of pa_stream_connect_record() as NULL. The easiest (maybe also the best, but I'm not sure) way to do this would be to set a property when creating the capture stream. So I propose that a new property will be introduced: media.target_device (better name ideas welcome). The property value should contain the "well-known" ID of the target device. I don't think there's any global ID namespace for all devices in the world, so the property could contain an OS and subsystem specific namespace prefix to make values unambiguous. For example, for V4L devices the prefix could be "v4l", so an application that wants to record from /dev/radio5, the property value would be "v4l:/dev/radio5" (I don't know if the devfs name is the most natural ID for V4L devices - if there's something better, then that should be used instead). How can the routing policy choose the right source then? Well, the alsa source still should have a property saying that "this is the source for the V4L device /dev/radio5" so the routing module can do the matching. I hope that the information is available somehow. I don't plan to implement the V4L/alsa mapping or the required new policy module at this point - for my purposes hardcoding the source in the N9 policy rules for streams with "media.target_device=v4l:/dev/radio" is enough. But I guess it has to be researched whether also the general solution is possible to implement. (OTOH, even if there's no way to automatically map the V4L devices to the alsa devices, making it possible to configure this manually is still better than nothing). -- Tanu
