Re: [pulseaudio-discuss] pax11publish -e -S
'Twas brillig, and Matt Zagrabelny at 05/11/10 00:57 did gyre and gimble: On Sun, Oct 24, 2010 at 11:48 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Matt Zagrabelny at 24/10/10 11:58 did gyre and gimble: On Sun, Oct 24, 2010 at 2:01 AM, Colin Guthrie gm...@colin.guthr.ie wrote: For what it's worth, when you first log into X11, PA loads the modules module-x11-publish (via start-pulseaudio-x11), which should export the properties you need and not require pax11publish to be run manually. I didn't mention that 'zombie' is a headless system and PA is running in system mode. Oh right. I didn't fully read the previous email... turns out you're kinda approaching the problem in the wrong way... I'll explain below. Make sure you are not using padevchooser as it's messes about with the x11 properties and the default setup should be sufficient for your needs. Sure. I've stayed away from padevchooser after seeing recommendations to not use it on the list. Its interface is still pretty nice, though. Just out of curiosity, is it possible to send one application to another SINK/SERVER or do you need to send all of your local audio traffic to it? Yes. You can do this one of two ways. The first way is a bit brutal: do something like: export PULSE_SERVER=zombie; my-sound-producing-application this will tell your app to talk _directly_ to the zombie's PA server. And here is where things get interesting. You probably don't _want_ to get your localhost to talk directly to zombie, but rather go through a tunnel sink. Tunnels appear in your local PA and are the same as any other real output device except, as the name suggests, they are just tunnels over the network to the h/w on a remote machine. You can load a tunnel sink via: pacmd load-module module-tunnel-sink sever=zombie sink_name=tunnel That way you don't mess around with pax11publish, or padevchooser or client.conf at all, you just play to your local PA and when you want an application to output to zombie, just fire up pavucontrol and find the application in question under the Playback tab and move it to the remove device. You don't even really need to load the module-tunnel-sink manually as you can let avahi do this for you automatically. Just ensure you have module-zeroconf-publish running in your system-wide PA on zombie and then load up paprefs on your localhost and tick the box that says Make discovered devices on the network available locally or something similar. This setting in paprefs will load module-zeroconf-discover in your localhost PA and thus load module-tunnel-sink for you automatically when it finds one. This needs a working avahi setup obviously, but you can debug that with avahi-browse -ta on your local machine. Suppose I wanted to do this without avahi? I've done the following: pacmd load-module module-tunnel-sink sever=zombie sink_name=tunnel Welcome to PulseAudio! Use help for usage information. Module load failed. % So I tweaked the command a little: pacmd load-module module-tunnel-sink server=zombie:4713 sink=alsa_output.hw_0 format=s16le channels=2 rate=44100 sink_name=tunnel.zombie channel_map=front-left,front-right Welcome to PulseAudio! Use help for usage information. % It looks a little better. pactl list | grep tunnel || echo not found not found But I still don't see the tunnel device. Any ideas? I didn't realise that the tunnel module needed some of those arguments by default but hey ho. It looks like your module load is all correct but for some reason it subsequently failed to connect and ultimately unloaded itself again. You'll really need to run the daemon with verbose logging to see what happens here. I'd imagine there is a permission problem with talking to the remote end. e.g. auth-anon is not set on the remote end and they are using different cookies. 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Add a new target to Pulseaudio log feature
Hi all, I would like to add in the log feature of PA a way to log(redirect) 'pa_log_*' messages in a file, which can be a char device for ex. That means adding a target to the log of pulseaudio. This target is not settable yet and I made changes in Pulseaudio for enabling a new log target of file type. Would it be possible to add them in Pulseaudio and shall I create a ticket for this ? Could you provide me some details in the process of upstreaming on PA.org ? I can quickly provide the code for our needs. Thanks Vincent BECKER Intel - Wireless System Integration Engineer Medfield platform - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Add a new target to Pulseaudio log feature
Dear Vincent, Am Freitag, den 05.11.2010, 14:10 + schrieb Becker, VincentX: […] Would it be possible to add them in Pulseaudio and shall I create a ticket for this ? Could you provide me some details in the process of upstreaming on PA.org ? I can quickly provide the code for our needs. please send a patch to this mailing list for review. $ git format-patch -1 -s $ git send-email 0001… # not required, you can also attach the file Thanks, Paul PS: Please send only plain text messages. signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Add a new target to Pulseaudio log feature
I would like to add in the log feature of PA a way to log(redirect) ‘pa_log_*’ messages in a file, which can be a char device for ex. That means adding a target to the log of pulseaudio. This target is not settable yet and I made changes in Pulseaudio for enabling a new log target of file type. Can't you just configure the setting below in client.conf? ; extra-arguments = --log-target=syslog -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Exponential recovering from rewinds
On Fri, 2010-11-05 at 09:15 -0400, David Henningsson wrote: Just following up on an idea brought to my attention at the Ubuntu/Linaro Developer Summit, and I'm not sure whether this is the original idea or if I refined it a little myself. Anyway. Since rewinds often come in chunks, and sometimes there are no rewinds for a very long time, it makes sense to not fill up the entire buffer immediately after a rewind. I propose the following algorithm: 1. After a rewind, write only 250 ms (or a configurable value) of data to the buffer. Then go to sleep and set to wakeup 250 ms later (minus the tsched watermark). 2. Now write 500 ms to the buffer and go to sleep. 3. Write 1 s to the buffer and go to sleep, and so on. Continue until the entire buffer is filled, and we'll then fall back to normal handling, or if we get a new rewind at any point, start over from point 1. This would enable ARM (and others) to go to low-power modes for long periods of time, while not risking to throw away a lot of processing due to several rewinds in a short period of time. I briefed Lennart yesterday about this and he seemed positive to the idea, and I guess Linaro are interested in contributing to the implementation. Any thoughts, comments etc? I had the impression that this was already planned by Lennart, and I haven't heard any objections before, so I think it's quite safe to go forward and implement this. One thing that wasn't mentioned in your algorithm was that the tsched watermark should probably increase at every iteration so that there's a larger safety buffer when working on rendering 10s of audio than when only 250 ms needs to be rendered. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
