[Kde-hardware-devel] Phonon and Solid

[Kevin Ottens]

Le Mardi 28 Mars 2006 19:31, Matthias Kretz a écrit :
> to finally get us started on the overlap of Phonon and Solid:
> http://vir.homelinux.org/audiodeviceconfig_solid.png

Nice diagram. =)

Ok, I think it's not desirable to have a connection between the persistent 
device list and solid. In particular because your persistent device list 
needs to hold both physical devices and virtual devices. That said, I could 
provide an helper class that would act as a "persistent storage" for device 
data, but since it seems your needs are really limited I'm not sure it's 
worth it since it wouldn't be reused.

> The goal is this:
> The user plugs a new device into his computer
> -> Solid recognizes that this could be interesting for Phonon

Well, I'm not really fond of a solid->phonon depend. As I see it we have two 
solutions:
1) Phonon apps listen to Solid events (we provide the necessary signals), and 
get notified for devices changes
2) Solid provides a policy manager, and Phonon can register an helper 
application there. This helper would be launched when particular conditions 
are met.

Davidz: btw, 2) reminds me about an obscure to-be-written fd.o spec... ;-)

> -> here could be a necessary step to configure the hardware and drivers so
> that the Phonon backends can make use of the hardware
> -> Solid tells Phonon, which asks the backend for a new listing of all
> available output devices

That should be in the hypothetic helper application IMHO.

> -> if a new device is in the list it is added to the persistent device list
> and a passive popup tells the user that a new audio output is available and
> asks whether he wants to open the output device configuration
> (http://vir.homelinux.org/deviceconfig.png).

Idem.

> -> the device is unplugged, but the output device configuration still lists
> the device (probably should be marked as "currently not available"). Here
> another notification could be needed:
>   The removal of a USB soundcard can happen while the device is still in
> use. The Phonon frontend then needs to ask the backend to use the next
> device from device preference list.

Once again the signals are already here.

> Now we have a problem when devices are removed that will never be used
> again. There needs to be a way for the user to remove entries from the
> persistent device list...

Well, I agree with Hugo here. It should be possible to the persistent device 
list to forget an entry if it hasn't been used for too long.

> A list of devices that Phonon wants to be notified about (probably the last
> one is not Solid's responsibility):
> - ALSA devices
> - OSS devices
> - any other platform specific audio hw devices

Ok, that's where I'm particularly interested to know which interface I should 
provide. Currently you'll be notified about the devices, but you can't know 
that they are interesting to you.

What I would like to know is exactly the information you need from a device 
(apart the fact that it's actually an audio output/input whatever).

Currently using the HAL solid backend I can expose the following information:
http://webcvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html#device-properties-alsa
http://webcvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html#device-properties-oss

That looks pretty exhaustive to me... To the point that I don't see the need 
to have your own device detection in your phonon backends (configuring the 
device and actually outputing to it of course belongs to your phonon 
backends). Otherwise, I have the feeling that we're duplicating the detection 
logic, and I'd prefer avoid it.

I might be wrong of course, I'm not the multimedia expert. ;-)

> - computers on the network that are useable as outputs

Clearly this last category is out of my scope. ;-)

I'm not sure I address all your concerns, but at least we have some more 
thought for food... Now we have to find the best way for both projects to 
interact.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060329/7d3245f3/attachment.pgp