レナート   Wunschkonzert, Ponyhof und Abenteuerspielplatz   ﻟﻴﻨﺎﺭﺕ

Posted by tanuk at Thu Feb 26 19:42:38 2009
The interface name "org.freedesktop.ReserviceDevice1" looks like a typo.

Posted by Tomasz at Thu Feb 26 20:14:54 2009
Nice but... session bus? Shouldn't it be system bus? What about two simultanous logged users, each with his own session. If there is no system PA, their daemons shouldn't fight for the same device.

Posted by Karellen at Thu Feb 26 20:53:04 2009
HAL going away pretty soon? Uh, really? Any more info on that?

I thought that X.org had just made their input drivers more integrated with HAL, in order to better support input device hotplugging and a whole bunch of other stuff. I try to keep up with Linux stuff generally, and have heard nothing about HAL "going away" anywhere.

Or are you talking about some other HAL?

/confused.

Posted by Lubomir Rintel at Thu Feb 26 21:03:18 2009
Karellen:

http://lists.freedesktop.org/archives/hal/2008-May/011560.html

http://fedoraproject.org/wiki/Features/DeviceKit

Posted by Lennar at Thu Feb 26 21:12:27 2009
tanuk: thanks, fixed

Posted by lennart at Thu Feb 26 21:19:19 2009
Tomasz: Handover between sessions has long been supported by PulseAudio based on ConsoleKit/HAL: as long as the the session PA was run in is active it opens the device. The missing part is too allow other software in the current session to take over the device temporarily. That's what this spec is for.

Posted by Tomasz at Thu Feb 26 21:42:52 2009
I meant simultaneous logged users. Each with own keyboard, mouse and monitor. Not user switching as we have now.

Posted by Karellen at Thu Feb 26 21:44:48 2009
Ah, it's a Fedora thing. :-)

Yes, I do recall hearing the name DeviceKit now. I just assumed it was going to be something that sat on top of or alongside HAL.

Damnit. It seems like only a couple of years ago that HAL was the new hotness which amazed everyone by solving all the possible hardware problems that could ever exist and get rid of the old and busted hotplug. Now HAL is old and busted? Man ... I'm getting too old for this.

Anyway, thanks for the info.

Posted by Lennart at Thu Feb 26 21:52:07 2009
We consider a sound card to be part of a seat along with screen/mouse/keyboard. Multiseat support in ConsoleKit is basically existant. And if CK can do it, then PA can do it too.

Posted by Lennart at Thu Feb 26 21:52:49 2009
Karellen: DeviceKit is exactly as much a Red Hat/Fedora thing as HAL.

Posted by Justyn at Thu Feb 26 22:59:19 2009
I'm a user and I'm very happy at the prospect of being able to run JACKd without completely disabling PulseAudio. Currently it is a real PITA to use JACK on a PulseAudio (which I love) system. I'm really looking forward to this.

Posted by Alexander E. Patrakov at Fri Feb 27 07:40:12 2009
What's missing in the spec is the clearly-specified way to add devices that should be handed over. Right now, it looks like this:

For OSS and ALSA hardware devices with kernel drivers, use org.freedesktop.ReserveDevice1.AudioN. For anything else, handover is not supported until a new revision of this document appears.

Now suppose that PulseAudio learns how to interact with FireWire audio cards directly through ffado, and thus sees a need to handover them from JACK. Who should decide on the service name - PulseAudio or JACK guys?

Posted by Lennart at Sat Feb 28 08:13:26 2009
Alexander: both of us! Exactly like we decided on the ALSA sound card identifiers!

Posted by multiple streaming or hardware mixing at Tue Mar 3 03:28:57 2009
will the implementation block the sound cards which support multiple multiple streaming or hardware mixing (i.e. sound card which have multiple subdevices , hw:0,0,0  , hw:0,0,1 , hw:0,0,2 )

they currently allow pulseaudio run on hw:0,0,0 and jack on hw:0,0,1

Posted by AD198x Analog at Tue Mar 3 13:00:29 2009
reservation can be done by using the subdevice_count and subdevice_avail in /proc/asound/cardx/pcm0p/info or /proc/asound/cardx/pcm0c/info

by parsing the /usr/share/alsa/cards/*.conf to find out the definition of hw:x,y,z of the slaves pcm of those surround40 surround51 ice958 and hdmi

and check the subdevice_avail of that device is greater than zero


cat /proc/asound/card1/pcm0c/info
card: 1
device: 0
subdevice: 0
stream: CAPTURE
id: AD198x Analog
name: AD198x Analog
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 3
subdevices_avail: 3

Posted by Luiz Augusto 'vudentz' von Dentz at Thu Mar 19 04:54:14 2009
lenny lenny, no need to return bool on RequestRelease, use dbus errors so the application holding the lock say more than "no I won't give up the lock" but the real why. Versioning the whole dbus is just nasty, it will just make the life of bindings introspection aware/fully automated miserable. Change a single parameter to something else and bump version and than you realize you had broken all testing scripts, bad idea.

Posted by Mikhail Zabaluev at Sun Apr 19 14:56:22 2009
This works as a simple immediate solution where all involved applications agree to cooperate.
For a generic resource locking/arbitration/policy application solution, this one has a few problems to solve.
1. There is no central entity where policies may be defined, some useful scripts ran, etc. without the need to modify every application. Part of this problem is applications assigning priorities to themselves. You can't know in advance what other applications may be installed in a system, so application-defined priority will inevitably fail, or worse, result in escalation that will make it useless.
2. Simple exclusive locking may be too inflexible for some cases. You mention the unavailability of finer recording vs. playback locks in this API.
Other possible cases are devices with capped number of simultaneous users, which is larger than 1.
3. It's impossible to coordinate locking of multiple resources, all or some of which may be claimed by other applications in arbitrary order.