'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: >> > In e193c2bf55326a48e2297bcacadc9d1848a40d7d and >> > 948d0f19bef353208ffb5b1b8c520b6b489b94a6 >> > >> > Can you make sure that pactl and pacmd stay as in-sync as possible? > I held off because I thought that pacmd was going to be dropped before > too long. Is this not the case? Sink port information seems to have not > been added, I'll sync that as well if required. Hmm, not sure. Ideally I'd prefer to just have one tool and only add to pacmd the things that cannot easily be done via the protocol, but I'm not sure of the overall strategy. I'll add this to the discussion points for Saturday's chat. >> > In bb7cc499f1815de1c90b0ef1850152224df96ff9 >> > >> > I don't see why this asserts in the current form nor what has actually >> > changed. > It should not assert since we want to gracefully fail (that is the > original code should not have been an assert). I still don't see any asserts in the original code. The only difference I can see is that a pa_log_debug() is not printed... (the log message says the word "Assertion" but it doesn't actually assert AFAICT...) This might be intended (i.e. don't print the log message), but if that's the case the commit message is still wrong to mention asserts... >> > General Question: >> > >> > Has this broken tunnels? (we manage to do this quite often with stream >> > protocol changes... > Indeed, it does. I've put fixing this on my TODO list. Will try to get > to it soon. Cool, thanks :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]