[pulseaudio-discuss] Proposal for new media role: fmradio

[Tanu Kaskinen]

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