Yo 'Twas brillig, and Lennart Poettering at 17/02/10 15:18 did gyre and gimble: >> Indeed. You've not specifically mentioned the fact that I'm really >> proposing three priority/history lists (per-app, per-role, default) that >> should be checked in order so I'm not sure how signed up you are to that >> idea overall, but the general principles at play here are certainly not >> much different. > > This is actually a point I am firmly against. This would basically > mean that the key we read data from the database with might be a > different one from the key we store data in the database with. I'm beginning to think that you didn't actually grok the plan fully with this comment. One of the main points I made was that this key (stream-restore-id) is a fundamentally broken concept. > Also, just think of the use cases. if I look at my setup here: i have > a bt headset for voip, internal laptop speakers for event sounds and > my hifi via spdif for music/video. That means the output ports I > choose by the role of the audio streams I play. However, you are > suggesting to save/restore stuff primarily per-app. That's not really what I said. I am proposing three priority lists that are checked *in order* to find a suitable default device. It fully permits the per-role based setup as you want it, but it *also* supports per-app - i.e. it caters for both cases and doesn't mask key PA capabilities. First you check the *application* list, then if you don't find an available device (or the list is empty which it would be in the default case if no pa_context_*_move_*() API calls have been used for that stream), then you check the "role" list (iff the stream has a role) and then you check the *default* list (or if you prefer the role list for the pseudo role "none"). As I stated earlier the concept of using the stream-restore-id for all applications is IMO broken. When we get all applications providing nice metadata it becomes impossible to move an *application* to a new device without affecting all roles. As you pointed out you can move a specific instance of an application to a new device without affecting another instance that is currently running at the same time, but when the stream is recreated (e.g. track change or app restart depending on implementation) a different device is used. This is IMO not very user friendly. Imagine someone hits stop and then play in their media player or just skips a track and it changes device? Really not nice. Any move should happen when the user triggers something (i.e. hits a button in a GUI, plugs in a device etc.) not when they do not expect it. With my approach you *can* change only the "Music" applications with the appropriate new API call, but likewise you retain full control over things at a per-application level. Thus it's more flexible and sacrifices nothing. > That would mean > Rythmbox and Banshee would get saved/restored devices > independantly. But that simply makes no sense. I am pretty sure you'll > find very few people on this world who have two hifi decks, one for > the stuff they play with banshee and another one for the stuff they > plan with rhythmbox. Yes Rhythmbox and Banshee *could* share the same role-based list but likewise allowing control of them independently is also useful. e.g. I may run MythTV or XBMC (video role) via my HDMI (where their display goes too) but want to run Rhythmbox/Banshee via my local speakers. Such cases are not totally unheard of. All I'm saying is that we should allow this to work. The UI you want is still fully possible via the structure I propose. The logic is just a tiny bit different at the client side: Instead of: pa_context_*_move_by_*(); It is: if (stream_has_role) ext_pa_context_*_role_move_by_*(); else pa_context_*_move_by_*(); If you want I could even internalise this logic in a user preference in daemon.conf meaning no external change if appropriately configured but I personally don't think this is necessary considering how many clients out there use the move API. That said, I wouldn't recommend a UI presents it this way anyway. It should offer a very specific UI to move whole role to a different device. If the UI does not offer the ability to move streams to a device then the per-app priority list will never be populated and thus never come into the equation when deciding where to route a stream. > Note that this all is for picking good defaults only. Whatever we pick > by default, the user can still manually override. That's exactly what is *not* possible right now! Control is taken away from the user and the way things operate is inconsistent and thus confusing. If an application provides metadata it operates in one way and if it doesn't it operates in another. As a user I don't know if an application provides a role or does not. Even when all applications do provide a role, as a user I don't always want to move everything from that role to the new device. If the UI presents me with a widget for a specific application and has a menu/dropdown/whatever to move to another device I expect to be able to move just that application. If you do ultimately insist on this behaviour then I'd strongly recommend that any client that offers stream moving capabilities be updated to not show the move option for any streams with a role and provide a different way to move whole roles to new devices instead. Either that or the client should make it very clear to the user that they will be moving all music streams and not just this one. This would at least make it clear to users what the hell was going on. Regardless, this is still externalising what should be internal logic to the clients - they'd have to check if m-s-r was loaded before calling what should be a core API so they can present the UI correctly. > So even if there in > fact do exist weirdos who want to pass rb audio to hifi #1 and banshee > audio to hifi #2, they can still configure things manually and it will > work. > Of course, we won't automatically save/restore these settings > for them, but I can live with leaving those weirdos out in the > cold. They are not the common case, they are the exception. You don't really support it because the stream will only play on their desired device until the track changes. That's hardly what I'd call "supporting" such a use case. But I don't see why we can't support this. The amount of effort required is relatively minimal and coded at a high level and I'm already volunteering to do the work. I really don't see the logic of cutting off some genuinely useful functionality. > So, I really don't see the use case here, and I am concerned about > using different keys for the db reads and writes. There wouldn't be different keys, the whole concept is not based around storing a stream-restore-id anymore, it's gone, it's not there, disappeared. It's based around a three tiered list of priorities checked in order. The APIs to work with these lists have pre-defined, consistent results. This whole thing can be summed up with two points: 1. The value of stream-restore-id causes API calls to work in an inconsistent manner. Clients will need to grok a lot of information and re-implement core logic in order to present the user with a UI that is clear and makes it obvious what is going to happen. 2. Streams which share the same stream-restore-id will *not* be moved when one of them is updated, but *will* use the new preference at the next opportunity - the next opportunity being: 1) when a track is skipped 2) play/stop hit 3) application restarts or 4) the stream restore database entry is updated by a client. This is a pretty alarming thing to happen when you don't expect/trigger it. So really I'm not arguing that your end goal is invalid, just that the implementation that relies on a single stream-restore-id and ultimately triggers inconsistent results from API calls is thus broken by design. I'd much rather expose APIs (optional ones via extensions rather than core) that act and behave in a consistent manner. It ultimately simplifies the clients and keeps the routing logic very clear and nailed down. Hope I've managed to explain things better this time. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
