Re: [pulseaudio-discuss] My default sound devices are not retained after suspend or reboot
2010/2/12 Colin Guthrie gm...@colin.guthr.ie: 'Twas brillig, and Sebastien Pimenta at 12/02/10 09:41 did gyre and gimble: Hi thanks for the tip, I'll give it a try but I'm using shoutcast, don't know if it will work too. Moreover my main problem is that the default pulseaudio card changes each time I reboot (got a EMU0404 - a webcam and a intel sound card). So it is annoying to change the settings each time I want to run a broadcast :/ It wont be a problem. The default wont matter (it shouldn't change every time you boot but that is another issue) as once you move the *stream* once, the *stream* device choice will be recorded and restored. The default device is only ever used if no more appropriate device for a given stream is available. But using the gst-launch command results in PulseAudio recognizing the stream as 'gst-launch'. So in order to have PulseAudio remember the settings of several different streams all started with a gst-launch command, you have to set some environment variables. See http://pulseaudio.org/wiki/ApplicationProperties The other option is to set the device parameter of the GstPulseSrc element, but you'll lose the advantage of PA remembering the selected output device. Maarten 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] PulseAudio - Network Streaming to sound card issues.
Here is a explaination of how ive been about things and what my issues are: Computers: laptop - Lucid Ubuntu 10.4 - PulseAudio 0.9.21-32-g8478 Compiled with libary version: 0.9.14 desktop- Karmic Ubuntu 9.10 - PulseAudio 0.9.19 Compiled with Libary Version: 0.9.14 Desired setup: laptop = slave desktop= master I'm trying to get my Desktop to broadcast the music on BOTH laptop and desktop's speakers Software/Gui's: pavucontrol pavdevchooser paprefs The only way i could obtain any kind of results was by using pavdevchooser, with the following settings: In the paprefs of BOTH the desktop laptop, gui i have the following: Network Access Make discoverable PulseAudio network sound devices available locally Network Server Enable network access to local sound devices Allow other machines on the LAN to discover local sound devices Don't Require authentication Everything else is unticked, including the multicast/RTP tab and Simultaneous Output At this stage, pavdevchooser can see both machine's server on each computer. how ever the only way i can get audio played on an oposite computer, is it set, lets say in this case the hyperstream-desktop to have a default server of the hyperstream-laptop, then if i open a rhythmbox player and play, it will play ONLY on the hyperstream-laptop, but not on its OWN speakers. And vice versa if i do it around the otherway. How ever someone in the #pulseaudio channel, told me pavdevchooser is outdated, and to use pavucontrol. also that on the laptop i should only enable the Network server and the two sub options, and on the master to enable the network access sub option. The only other horrible way i have manage to stream music is to setup the laptop as a multicast/RTP receiver, and the desktop as a multicast/RTP sender, but as im sure you are aware it goes out of tune, out of sync, and isnt very nice at all. I had a friendly user in #pulseaudio attempt to show me how to use the pacmd to do it 'manually', but i have failed lol, i will demostrate how to reproduce the error: (THIS IS DONE ON THE MASTER (desktop - the desktop machine has itself set as server at this stage and is playing sound through its own speakers)) run pacmd in a terminal: load-module module-tunnel-sink server=hyperstream-laptop list-sinks (THIS IS WHERE I GET LOST, i was asked to take note of the 'name of tunnel sink' and the 'local sink') 2 sink(s) available. * index: 0 name: alsa_output.pci-_00_06.1.analog-stereo driver: module-alsa-card.c flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY state: SUSPENDED suspend cause: IDLE priority: 9959 volume: 0: 47% 1: 47% 0: -19.63 dB 1: -19.63 dB balance 0.00 base volume: 100% 0.00 dB volume steps: 65537 muted: no current latency: 0.00 ms max request: 1 KiB max rewind: 64 KiB monitor source: 0 sample spec: s16le 2ch 44100Hz channel map: front-left,front-right Stereo used by: 0 linked by: 2 configured latency: 0.00 ms; range is 1.00 .. 371.52 ms card: 0 alsa_card.pci-_00_06.1 module: 4 properties: alsa.resolution_bits = 16 device.api = alsa device.class = sound alsa.class = generic alsa.subclass = generic-mix alsa.name = ALC888 Analog alsa.id = ALC888 Analog alsa.subdevice = 0 alsa.subdevice_name = subdevice #0 alsa.device = 0 alsa.card = 0 alsa.card_name = HDA NVidia alsa.long_card_name = HDA NVidia at 0xf96f irq 21 alsa.driver_name = snd_hda_intel device.bus_path = pci-:00:06.1 sysfs.path = /devices/pci:00/:00:06.1/sound/card0 device.bus = pci device.vendor.id = 10de device.vendor.name = nVidia Corporation device.product.id = 0371 device.product.name = MCP55 High Definition Audio device.form_factor = internal device.string = front:0 device.buffering.buffer_size = 65536 device.buffering.fragment_size = 32768 device.access_mode = mmap+timer device.profile.name = analog-stereo device.profile.description = Analog Stereo device.description = Internal Audio Analog Stereo alsa.mixer_name = Realtek ALC888 alsa.components = HDA:10ec0888,18491e01,0011 module-udev-detect.discovered = 1 device.icon_name = audio-card-pci ports: analog-output: Analog Output
Re: [pulseaudio-discuss] PulseAudio - Network Streaming to sound card issues.
'Twas brillig, and hyperstream at 16/02/10 12:08 did gyre and gimble: run pacmd in a terminal: load-module module-tunnel-sink server=hyperstream-laptop list-sinks (THIS IS WHERE I GET LOST, i was asked to take note of the 'name of tunnel sink' and the 'local sink') 2 sink(s) available. * index: 0 name: alsa_output.pci-_00_06.1.analog-stereo index: 1 name: tunnel.hyperstream-laptop.local.alsa_output.pci-_00_1b.0.analog-stereo These are the two names here. load-module module-combine master=alsa_output.pci-_00_06.1.analog-stereo slaves=tunnel.remote.sink Module load fails. Your slaves name is wrong. It's not the name assigined to the sink itself which you listed above. Also, I believe that the combine sink no longer needs a master argument and you can support all the devices as slaves. load-module module-combine slaves=alsa_output.pci-_00_06.1.analog-stereo,tunnel.hyperstream-laptop.local.alsa_output.pci-_00_1b.0.analog-stereo# As you can see, i cannot find a name for the local sink tunnel, so im using the name of the index 0 sink. No you're not, you're using a made up name :p PLEASE NOTE: on the after the last steps, the desktop is sending 180KB's outgoing. the laptop is not receiving anything. Does the tunnel work by itself? Have you made sure that it is physically working before you try and use it as a slave of the combined sink? You should test each stage. You can test easily via: PULSE_SINK=tunnel.hyperstream-laptop.local.alsa_output.pci-_00_1b.0.analog-stereo mplayer /path/to/a/file.mp3 (or any PA application) You could also just produce some sound locally then move the stream to the tunnel from the Playback tab in pavucontrol. Hope this helps. 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Thu, Feb 11, 2010 at 12:29 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 10.02.10 09:59, Markus Rechberger (mrechber...@gmail.com) wrote: this is another wrong assumption, libusb uses raw USB access, if every user would have access to USB some devices might be damaged. Sane would need to be serverbased, full raw access to the usb bus would seriously be a security risk (imagine RAW USB access to a USB harddisk). This is nonsense. Since ages we by default add ACLs for the console user for libusb devices for cameras, scanners, and so on. That too works via udev-acl. Lennard, don't spread nonsense around, if you have raw access to a camera there might be the possibility to update the firmware and damage the device. If you would have little experience with hardware you should know about that. Your ACL/libusb restriction won't make this situation better it's still a security risk. Although just drop libusb as an example. Markus You are spreading FUD and lies. You are annoying. And are stealing my time. I'd prefer if you'd waste other people's time, and stop lighting up the flames of this flamewar over and over again. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 16.02.10 20:48, Markus Rechberger (mrechber...@gmail.com) wrote: Lennard, don't spread nonsense around, if you have raw access to a camera there might be the possibility to update the firmware and damage the device. If you would have little experience with hardware you should know about that. Your ACL/libusb restriction won't make this situation better it's still a security risk. Although just drop libusb as an example. Markus Marcus, then you better run quickly and complain to the udev folks, because they have been shipping udev with libusb devices accessible to console users sine about forever. Just plug in a USB scanner on a reasonably new Linux machine and run ls -al /dev/bus/usb/*/*. Then, look out for the + in the permissions column and run getfacl on that file, and you'll see that the logged in user may access the device node. But all of this has nothing to do with PA. So please go away, and complain elsewhere. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 16, 2010 at 10:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 16.02.10 20:48, Markus Rechberger (mrechber...@gmail.com) wrote: Lennard, don't spread nonsense around, if you have raw access to a camera there might be the possibility to update the firmware and damage the device. If you would have little experience with hardware you should know about that. Your ACL/libusb restriction won't make this situation better it's still a security risk. Although just drop libusb as an example. Markus Marcus, then you better run quickly and complain to the udev folks, because they have been shipping udev with libusb devices accessible to console users sine about forever. Just plug in a USB scanner on a reasonably new Linux machine and run ls -al /dev/bus/usb/*/*. Then, look out for the + in the permissions column and run getfacl on that file, and you'll see that the logged in user may access the device node. Sure but this doesn't mean that it's right and is a security issue. It's like making CPU levels obsolete just because someone made the mistakes to run everything at Kernellevel. Almost all available USB TV Tuners use to run with a firmware nowadays, even by loading the wrong firmware into a chip a chip can blow up. If every user has the possibility to access devices at a raw level (not at a defined API level) ...everyone can do that. But all of this has nothing to do with PA. Indeed, but this ACL example came up by you guys, so you should better learn that this is not always the correct way. With your example this even turns out to be a security risk. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] set volume all sinks
On Mon, 15.02.10 17:02, poort (po...@telenet.be) wrote: Thanks, But I was thinking on a script that will be called with GDM's Postlogin default script.The script should find the user's default sink and put the volume to max or 80 % with set-sink-volume users default sink 55000 Uh, that's a very bad idea, as for cards with builtin amplifiers (such as USB speakers) 80% will blast off your ears. 80% has no defined meaning and will result in completely different volumes on different hardware. If at all use alsctl init 0 which is a lot smarter about coming up with good default, based on the hw in use. But that said it is presumably a much better idea to use the default logic which saves/restores the volume settings between sessions, as Colin pointed out. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] What is latency? And other related questions
On Fri, 12.02.10 09:20, David Henningsson (launchpad@epost.diwic.se) wrote: What happens here either there is a large period (~30 seconds to 90 seconds) of silence before audio begins to play fine, or I get bursts of audio (5-10 seconds) followed by very long bursts of silence. I know this is related to prebuffering, but beyond that I am lost. First, make sure that your tlength is at least two-three time as large as mixlen. My guess is that you supply a tlength but for some reason fail to fill it properly, so you get underruns on the PA frontend, which makes PA increase tlength even more, leading to higher prebuffering (and latency). Uh, 2-3x seems very arbitrary to me. I don't see where such a rule would ever apply. 2. How do the meaning of pa_stream_writable_size and pa_simple_get_latency differ in terms of the fill state of the buffer? pa_stream_writable_size returns the number of bytes that may be written using pa_stream_write. Actually, to be fully correct you are welcome to write both less or more than pa_stream_writable_size() returns. Generally however the rule is that you should pass at least what it returns. A good reason to pass more is when your app generates blocks of PCM and hence cannot generate the exact number of samples _writable_size() indicated. A reason to pass less is for example when you are reaching the end of your stream, or otherwise want to (temporarily or not) stop passing audio data. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] What is latency? And other related questions
On Sun, 14.02.10 11:13, David Henningsson (launchpad@epost.diwic.se) wrote: Tristin Celestin wrote: Is there a downside to making a version of pa_stream_writable_size available in the simple API? Good question. In your use case, can see the use for a function returning how many bytes that can be written to pa_simple_write without pa_simple_write blocking. Why would I want to specify the buffer attributes in the simple API with a buffer_attr, but not be able to query the state of the buffer while writing to it? If there is no free space in the buffer, the simple API blocks until all data you send to it has been written to the buffer. This is a good approach for some applications, although your app doesn't seem to be one of them. Perhaps it is a PA design decision that apps that don't want pa_simple_write to block, shouldn't use the simple API, I don't know. Yes, that is exactly the case. The simple API is supposed to be a simplified, synchronous version of the complex, asynchronous API. _writable_size() only really makes sense in an asynchronous API. WHich is why I see no point in adding it to the simple API. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] hda intel + Line-In + ext. mic
On Thu, 11.02.10 00:23, Николай Коротинский (magedon...@gmail.com) wrote: Hi all, I have a laptop Amilo Si 3655 and Ubuntu 9.10 64 Please read this before reporting bugs upstream. http://pulseaudio.org/wiki/UbuntuBugs I have 2 mic: internal and external. Internal mic work successfully. But external Mic and Line-In work as outputs. Line-In output surround channel. Mic output Center and LFE channels. But sometime I need external Mic and Line-In. How I can change channels on Line-In and Mic? This is called Jack Retasking. Most likely you have some kind of low-level ALSA mixer control that allows you to retask your jacks. Please check whether you can find one with alsamixer -c0. If you find a control like this and it is apparently not set properly when PA changes device profiles then this is probably something that should be fixed in alsa. i.e. when the surround51:x device string is opened ALSA should toggle the retasking controls to enable 6ch mode, and when the device is closed again or opened as front:x ALSA should toggle the retasking control back to 2ch duplex mode. This would then work similarly to how the SPDIF low-level controls are toggled when spdif:xxx is opened/closed. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, 10.02.10 18:49, Jeremy Nickurak (pulseaudio-disc...@trk.nickurak.ca) wrote: A question about the console-kit approach, where the user physically near the sound hardware is the person that gets to use it... A favorite trick of mine is to ssh into a machine, and use the sound hardware there to announce some kind of event. It might be an alarm to wake up a family member, or a remotely-generated event alert. It might not be SSH, it might be a cron job, or a CGI... Assuming I'm the administrator of the machine, how can I pull off this trick in the context of console-kit? If it's even possible, it sounds like I'd have to suspend the existing pulseaudio connection by assigning rights to a virtual console of some kind, which would then have the opportunity to use the audio device until it released it. If you are root you can do anything you want, including doing the baddest things to your audio devices you want. And as mentioned a gazillion of times in recetn distros even non-root users can do this, regardless whether they are logged in or not, if they are a member of the audio group. Incidentally, this seems to be the same use case that vision-impaired users were dealing with recently: How can system-level processes inject their inputs to the speakers without a system-level pulseaudio daemon sharing that hardware? Nope, there should not be a system-level process generating the speech audio. It should be a user/session process. Now, unfortunately the current solutions are mostly based on system daemons, but that doesn't mean that that would be the correct way to handle these things. Because it is not. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, Feb 17, 2010 at 12:25:27PM EST, Lennart Poettering wrote: On Wed, 10.02.10 18:49, Jeremy Nickurak (pulseaudio-disc...@trk.nickurak.ca) wrote: Incidentally, this seems to be the same use case that vision-impaired users were dealing with recently: How can system-level processes inject their inputs to the speakers without a system-level pulseaudio daemon sharing that hardware? Nope, there should not be a system-level process generating the speech audio. It should be a user/session process. Now, unfortunately the current solutions are mostly based on system daemons, but that doesn't mean that that would be the correct way to handle these things. Because it is not. There are a group of us gradually moving everything a11y, including speech output/audio into user sessions, and as discussed last month, an idle like user that consolekit/udev knows about is needed for those speech/audio processes that users want to use so they can get a text console login screen to be usable. Should nobody else get to this in the coming months, this is on my agenda. Luke ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Add rtkitctl manpage
On Mon, 18.01.10 14:27, Luke Yelavich (them...@ubuntu.com) wrote: As Lennart asked about the rtkitctl manpage Ubuntu has, here is a patch against rtkit git. Thanks a lot! Applied. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] rtkit: Add client-side testing of properties
On Sun, 07.02.10 13:59, David Henningsson (launchpad@epost.diwic.se) wrote: To complete the previous patch that implemented properties in rtkit, here's the client-side code that tests that the properties work, and make them more accessible for the casual C programmer. Thanks a lot! Applied (with trivial changes). Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatically change 'Default device'?
On Mon, 15.02.10 17:13, Ng Oon-Ee (ngoo...@gmail.com) wrote: Wait no longer! http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ Col A nice read Colin, thanks. /me also wonders whether all these 'restore' options need to be made much more transparent. At the very least with a checkbox somewhere saying save per-stream routings. I believe in the simplest use cases (internal laptop speakers or BT headset on the move, USB headset at home), it would be advantageous to be able to specify that stream routings should NOT be saved, but that a device preference should instead be used. Of course, this is up to those who write the code (and I believe the same thing could be achieved by NOT loading module-stream-restore). I know that it would cover about 90% of my personal use-case though. My own thoughts about all of this are basically: 1) I think it is bad UI to expose the entire history of devices to the user and allow him to rearrange items in there. I am aware that KDE folks disagree with me on this and like stuff like that and Colin is willing to please them. 2) We definitely should save the device history for streams, and when it comes to finding a device for a stream go backwards finding the newest entry that is applicable and apply it. All of this should be automatic and opaque to the user. 3) If that didn't result in anything try to find a good default by some other means, i.e. by used intended roles and stuff like that. Should be automatic and opaque to the user as well. 4) The UI would allow the user to fix any setting the system chose and the system will then remember as good as possible. I think this is a simple enough scheme. Certainly, the logic in #3 (especially) might not be obvious to the user, but that doesn't matter: we have to default to something, and it's better to pick the most likely device in an non-obvious way than pick a completely random one. As I understood Colin's blog his suggestion mostly differs in that he wants apps to get full access to the device history and change it, so that what I call the history hence becomes more of a priority list. But uh, while I don't think that would be good idea UI-wise, if that's what makes KDE folks happy this should not be a stumbling block to to merge both approaches. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RFC stream-restore save_sink|source flag reset more musings on device selection.
On Fri, 05.02.10 10:11, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Recently I tried to write a client that would nuke the device part of the stream restore database. This works fine but any active streams that match the rule will not have their save_sink|source flag reset when this happens. I think the following patch does this but just wanted to double check this wouldn't trigger some other unwanted behaviour (e.g. in gnome apps) before I push it. I also generate a sink input|source output change subscription message here. This is arguably not correct as the sink input itself is not changing, although the rules governing it's routing have. In lieu of a proper subscription system for routing rules I just fire this one. Comments? http://colin.guthr.ie/git/pulseaudio/commit/?id=7a7c7e53914f641686fe3fe59d0772e78cdf86ca Hmm, we actually try pretty hard to supress subscription events if we can. Since the only thing you change about the sink input is the save_sink flag I see no reason to fire the event. The primary purpose of the subscription event is to notify clients about changes, but they have no access to the save_sink flag at all. I'd advise to not fire the subscription event here, unless an existing module really needs this. (Though generally I am tempted to say that modules that care about save_sink and the routing stuff should use synchrnous hooks rather than asynchronous subscriptions) But otherwise the patch looks fine to me, and makes a lot of sense to me. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] regression in pacat
On Thu, 11.02.10 23:34, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Colin Guthrie at 11/02/10 22:52 did gyre and gimble: 'Twas brillig, and pl bossart at 11/02/10 21:41 did gyre and gimble: Hi Lennart, hope you had a good time in India. paplay seems to be broken in git master, git bisect tells me the culprit is: fb55798a3eb73b4c00225232408b766f74533409 is first bad commit commit fb55798a3eb73b4c00225232408b766f74533409 Author: Lennart Poettering lenn...@poettering.net Date: Fri Jan 15 01:25:21 2010 +0100 pacat: allow configuration of latency in msec With this commit paplay is stuck, there's no audio out and no update of time/latency. Ahh so that's where the problem lies... I'll try and fix if Lennart doesn't beat me to it. This fixes it for me: ff2091b pacat: Don't use any buffer attr if we don't set any latency/process time params May not be the nicest fix in the world but it'll do until Lennart can review properly :) Actually I had I really wanted to write what I wrote. i.e. passing NULL as buffer_attr means use the default latency (which is 250ms). Passing a buffer_attr with all values set to -1 means i don't care about latency (which ideally means 2s latency). So, yes, I actually meant what I did in fb55798a... Now the question is why this doesn't work for Pierre. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] regression in pacat
Actually I had I really wanted to write what I wrote. i.e. passing NULL as buffer_attr means use the default latency (which is 250ms). Passing a buffer_attr with all values set to -1 means i don't care about latency (which ideally means 2s latency). So, yes, I actually meant what I did in fb55798a... Now the question is why this doesn't work for Pierre. I will retry tomorrow on a standard Fedora12/HDAudio config. Could be that my setup doesn't work with 'default' values, I always work with -1 values or way-smaller ones. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] new virtual-sink and virtual-source modules
On Thu, 11.02.10 16:47, pl bossart (bossart.nos...@gmail.com) wrote: The patches I am about to post provide two modules that could be of interest to the PulseAudio community. module-virtual-sink is a template for the addition of PCM processing. It's basically based on the LADSPA module, I use it for internal experiments and will enhance it in the future. This definitely makes sense, especially when we'll eventually get the filtering logic I have mentioined a couple of times. To enable both modules, just add these lines in default.pa load-module module-virtual-sink sink_name=vsink set-default-source vsink load-module module-virtual-source source_name=vsource uplink_sink=uplink set-default-source vsource I have merged both modules to master now since they look mostly good, and are not invasive. I'll have a closer look soon and fix what there is left to fix. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
On Wed, 03.02.10 16:38, João Paulo Rechi Vita (jprv...@gmail.com) wrote: On Tue, Feb 2, 2010 at 09:10, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.01.10 12:53, João Paulo Rechi Vita (jprv...@gmail.com) wrote: Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html I forgot to add, suspending of the sink/source seemed to cause disconnection by the AG, so you might want to disable module-suspend-on-idle when testing. BTW, Lennart, is there any way to mark a source/sink to not be suspended? Not really. As Colin mentioned you can make suspending a simple NOOP which does what you want. That said I do believe it makes a lot of sense to actually mark sinks as suspendable. I.e. Introduce a sink flag PA_SINK_SUSPENDABLE or so that we flag for all sinks that actually support suspending and leave unset fo all others, like yours. Even after figuring out suspending wasn't really causing any problem to my tests, it sounds like a good thing to have support for. Anyway, the patches look really good to me. I'd be happy to merge this, though is the bluez counterpart merged yet? (sorry, haven't closely followed bluez development for a while) BlueZ part is still not merged, the code is under peer-review now but it's likely to be merged soon. There may be some modification on which signals to listen in order to load module-bluetooth-device (for HFP case only), also. I'll send a patch rebased against git's head when the merging time comes. Is this merged now into Bluez? Or even released? If so I should probably merge your code into our master. Could you publish this on one of your public git trees? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] new virtual-sink and virtual-source modules
module-virtual-sink is a template for the addition of PCM processing. It's basically based on the LADSPA module, I use it for internal experiments and will enhance it in the future. This definitely makes sense, especially when we'll eventually get the filtering logic I have mentioined a couple of times. Humm, I am not sure I remember having seen anything on this 'filtering logic'. Would you mind providing a pointer to previous posts? I have merged both modules to master now since they look mostly good, and are not invasive. I'll have a closer look soon and fix what there is left to fix. Cool. Thanks in advance for your feedback. What I am now looking at is a way to handle sinks and sources in a more optimized manner for low-latency speech calls: it doesn't make any sense power-wise to handle uplink and downlink paths in completely separate threads with their own timers. You use the same latency settings,sampling frequencies and channel-map on both paths, relying on completely independent structures results in 2x wakeups for no good reason. Plus if you start doing processing you need inter-thread communication for acoustic enhancements. Maybe we could handle both threads with the same wake-up events (a single rtpoll?), or combine sink/source threads. I know no one cares with a 50 Wh battery, things are different in a handheld - Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
