Re: [pulseaudio-discuss] [PATCH] stream-restore: Check for readability before reading volume
On Tue, 2011-04-12 at 13:11 +0530, Arun Raghavan wrote: This avoids an assert in pa_sink_input_get_volume() when connecting a passthrough stream. Based on Tanu's comments on the previous version of the patch, this one should be correct. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Weird bug with Pulseaudio connections.
Hello everyone I haven't posted to this list before, not being much of a developer, but I've been having some really odd bugs pop up almost at random with Pulseaudio. Usually they disappear days or weeks later with just as much warning as when they occur, and I'm never sure whether I've solved them or whether my computer is just ... odd. Anyway, the main nature of the bugs is that Pulseaudio seems to have difficulty connecting to either ALSA, my sound card, or something else. I can't quite explain what's going on; I've tried reading through /var/log/errors.log and noticed that it is failing to set hardware parameters with a connection timeout. I'm not quite familiar with how Pulseaudio works, but from the odd arcane messages I get, I'm guessing that somewhere, somehow, it's trying to talk to my soundcard and my soundcard is responding with Computer says no. The weird bit is that the bug, if that's what it is, gets triggered by almost anything. Commonly, opening pavucontrol will kill sound for a few seconds to a few minutes: sound only resumes once I've killed pavucontrol, and a dialog/error box will pop up alerting me to a connection timeout. Given that pavucontrol is a really useful way of manipulating the volume of individual programs this can be quite annoying. Before I describe what methods I've attempted to solve the problems, I'll just briefly list my OS. I'm currently running Arch Linux, with (as of tonight) the latest (stable) kernel 2.6.38.2 according to my update logs. Pulseaudio itself is version 0.9.22. My desktop environment is Openbox, and I'm calling it within consolekit and polkit and whatever else it needs. The command being called from ~/.xinitrc is exec /usr/bin/ck-launch-session /usr/bin/openbox-session start-pulseaudio-x11 is also being called in this file, a few lines up. As for setting up my system, I think I've tried just about every guide there is, and there's a lot of conflicting information out there, especially on user and group permissions. Sometimes following a guide for the sake of it fixes the bug; that being said, I've already had the settings it recommends so I have no idea what's going on. I've experimented with setting sinks, with setting sound outputs, everything. But time and again this weird bug shows up, pulseaudio fails to load, or the pavucontrol applet brings the sound to a halt, or something. And without warning it'll start working again, usually within hours of me asking on a forum somewhere about the bug. As far as I know I've installed everything that might be needed. I used to like Pulseaudio, the whole control-volume-of-individual-streams is great. But it just doesn't work (between some of the time to most of the time). And yet it's one of those features, which once you get used to it, is really hard to live without. How can I fix this once and for all? If there's any configuration details or similar that you might need to be able to confirm or identify the bug or whatever conditions are causing this, let me know what you need to know and I'll try to assist in any way I can. regards Robbie ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] crackle and stutter
It seems inevitable that my pulse audio server (0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 on Ubuntu Maverick) will start sounding crackly and stuttery when an application wants to send notification type sounds. When this happens, about the only useful thing I see in the -vvv output is: D: alsa-sink.c: Requested to rewind 22988 bytes. D: alsa-sink.c: Limited to 22988 bytes. D: alsa-sink.c: before: 5747 D: alsa-sink.c: after: 5747 D: alsa-sink.c: Rewound 22988 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 22988 bytes on render memblockq. D: sink-input.c: Have to rewind 22988 bytes on render memblockq. D: sink-input.c: Have to rewind 11496 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 23120 bytes. D: alsa-sink.c: Limited to 23120 bytes. D: alsa-sink.c: before: 5780 D: alsa-sink.c: after: 5780 D: alsa-sink.c: Rewound 23120 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 23120 bytes on render memblockq. D: sink-input.c: Have to rewind 23120 bytes on render memblockq. D: sink-input.c: Have to rewind 11560 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue. D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 21480 bytes. D: alsa-sink.c: Limited to 21480 bytes. D: alsa-sink.c: before: 5370 D: alsa-sink.c: after: 5370 D: alsa-sink.c: Rewound 21480 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 21480 bytes on render memblockq. D: sink-input.c: Have to rewind 21480 bytes on render memblockq. D: sink-input.c: Have to rewind 10740 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 21848 bytes. D: alsa-sink.c: Limited to 21848 bytes. D: alsa-sink.c: before: 5462 D: alsa-sink.c: after: 5462 D: alsa-sink.c: Rewound 21848 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 21848 bytes on render memblockq. D: sink-input.c: Have to rewind 21848 bytes on render memblockq. D: sink-input.c: Have to rewind 10924 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue. D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 20212 bytes. D: alsa-sink.c: Limited to 20212 bytes. D: alsa-sink.c: before: 5053 D: alsa-sink.c: after: 5053 D: alsa-sink.c: Rewound 20212 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 20212 bytes on render memblockq. D: sink-input.c: Have to rewind 20212 bytes on render memblockq. D: sink-input.c: Have to rewind 10108 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 20336 bytes. D: alsa-sink.c: Limited to 20336 bytes. D: alsa-sink.c: before: 5084 D: alsa-sink.c: after: 5084 D: alsa-sink.c: Rewound 20336 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 20336 bytes on render memblockq. D: sink-input.c: Have to rewind 20336 bytes on render memblockq. D: sink-input.c: Have to rewind 10168 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue. D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 19012 bytes. D: alsa-sink.c: Limited to 19012 bytes. D: alsa-sink.c: before: 4753 D: alsa-sink.c: after: 4753 D: alsa-sink.c: Rewound 19012 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 19012 bytes on render memblockq. D: sink-input.c: Have to rewind 19012 bytes on render memblockq. D: sink-input.c: Have to rewind 9508 bytes on implementor. I'm not really sure what this is telling me though. Is the above normal? Is there something else I should be looking for? During these periods of crackle and stutter, other continuous sound output type applications, like audio/video apps seem to stutter as well as if they are being blocked on their output by the pulse server and it's attempting to handle these other periodic type applications that send notification sounds and so on. Thots? b. signature.asc Description: OpenPGP digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] keys for raop server
'Twas brillig, and Daniel Mack at 11/04/11 14:28 did gyre and gimble: 2011/4/11 Rémi Denis-Courmont r...@remlab.net: On Mon, 11 Apr 2011 12:39:38 +0200, Tomasz Torcz to...@pipebreaker.pl wrote: Some interested in adding server functionality to PA, using attached key? On a side note, I understood (from an Apple AirPort engineer) that there is no need to do the cryptographic stuff to SEND to an ApEx. If it's true, then many hoops in PulseAudio and VLC's RAOP outputs are nasically redumdant. Of course, for an RAOP input, you do need the cryptography (if the remote client asks). I'm not sure how well this fits into PulseAudio though? It does not have a decoder for Apple Lossless, does it? That's true. Streaming from another Mac would also only be interesting for iTunes, as all other applications are not (natively) able to stream to an Airport Express. However, a thing that really could be cool is streaming Music from an iPhone to a computer running PulseAudio. It's possibly something that fits better into VLC or GST etc, (just push a stream to the sound output), although PA does provide a nice framework for listening for it but I think the fact we'd only be able to handle PCM easily (without linking to GST/VLC or similar), it may be better implemented as a separate, but related project? Not really sure to be honest. If the whole crypography overhead can be skipped, in our current ROAP output stuff tho', that would be a bonus. I guess it'll take some trial and error experiments to work that out. 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
Re: [pulseaudio-discuss] rygel mediaserver
'Twas brillig, and Gunnar Aastrand Grimnes at 11/04/11 11:27 did gyre and gimble: Hi all, What is the status of the rygel mediaserver integration atm? In paprefs I can enable upnp/dnla sharing, and the services and stream appears in any players on my network, however, actually playing the stream does not work. I have tried with my WDTV box, a LG BlueRay+DLVA player and simply playing the stream locally with the upnp-inspector. I have also enabled the http-tcp module, as someone said this was needed. The rygel webpage says something about MediaServer spec v1 being deprecated, and that pulse needs to implement v2, but this appears to be done here: http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/module-rygel-media-server.c;hb=ff7acb4d059e21b318b0464ee6fd1785318071cc Does anyone have this working? Any hints for debugging what goes wrong? I think you have to load module-protocol-http as well (not sure I've got the name totally correct). I tried it with my PS3 but never got very far (it defo did try to talk to the http module tho') If you get it working with your WDTV box just by loading http protocol, please report back and I'll tweak paprefs. 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
Re: [pulseaudio-discuss] crackle and stutter
Hi, On Tue, Apr 12, 2011 at 11:14 AM, Brian J. Murrell br...@interlinx.bc.ca wrote: It seems inevitable that my pulse audio server (0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 on Ubuntu Maverick) will start sounding crackly and stuttery when an application wants to send notification type sounds. Can you give an example of what application(s) in particular trigger this? Is it reproducible 100% of the time, or just sometimes? How is your CPU load when this is occurring? When this happens, about the only useful thing I see in the -vvv output is: D: alsa-sink.c: Requested to rewind 22988 bytes. D: alsa-sink.c: Limited to 22988 bytes. D: alsa-sink.c: before: 5747 D: alsa-sink.c: after: 5747 D: alsa-sink.c: Rewound 22988 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 22988 bytes on render memblockq. D: sink-input.c: Have to rewind 22988 bytes on render memblockq. D: sink-input.c: Have to rewind 11496 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 23120 bytes. D: alsa-sink.c: Limited to 23120 bytes. D: alsa-sink.c: before: 5780 D: alsa-sink.c: after: 5780 D: alsa-sink.c: Rewound 23120 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 23120 bytes on render memblockq. D: sink-input.c: Have to rewind 23120 bytes on render memblockq. D: sink-input.c: Have to rewind 11560 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue. D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 21480 bytes. D: alsa-sink.c: Limited to 21480 bytes. D: alsa-sink.c: before: 5370 D: alsa-sink.c: after: 5370 D: alsa-sink.c: Rewound 21480 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 21480 bytes on render memblockq. D: sink-input.c: Have to rewind 21480 bytes on render memblockq. D: sink-input.c: Have to rewind 10740 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 21848 bytes. D: alsa-sink.c: Limited to 21848 bytes. D: alsa-sink.c: before: 5462 D: alsa-sink.c: after: 5462 D: alsa-sink.c: Rewound 21848 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 21848 bytes on render memblockq. D: sink-input.c: Have to rewind 21848 bytes on render memblockq. D: sink-input.c: Have to rewind 10924 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue. D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 20212 bytes. D: alsa-sink.c: Limited to 20212 bytes. D: alsa-sink.c: before: 5053 D: alsa-sink.c: after: 5053 D: alsa-sink.c: Rewound 20212 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 20212 bytes on render memblockq. D: sink-input.c: Have to rewind 20212 bytes on render memblockq. D: sink-input.c: Have to rewind 10108 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 20336 bytes. D: alsa-sink.c: Limited to 20336 bytes. D: alsa-sink.c: before: 5084 D: alsa-sink.c: after: 5084 D: alsa-sink.c: Rewound 20336 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 20336 bytes on render memblockq. D: sink-input.c: Have to rewind 20336 bytes on render memblockq. D: sink-input.c: Have to rewind 10168 bytes on implementor. D: source.c: Processing rewind... D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue. D: protocol-native.c: Requesting rewind due to rewrite. D: alsa-sink.c: Requested to rewind 19012 bytes. D: alsa-sink.c: Limited to 19012 bytes. D: alsa-sink.c: before: 4753 D: alsa-sink.c: after: 4753 D: alsa-sink.c: Rewound 19012 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 19012 bytes on render memblockq. D: sink-input.c: Have to rewind 19012 bytes on render memblockq. D: sink-input.c: Have to rewind 9508 bytes on implementor. I'm not really sure what this is telling me though. Is the above normal? Is there something else I should be looking for? Some amount of rewinds are normal. Especially when the server first starts up, or when the amount of latency demanded by an application is very low while system load is high. But excessive rewinds can be due to a driver bug in ALSA (this would have to be specific to your hardware since I can't reproduce the issue here on Maverick). I like to compare it to an anti-lock break system: if it engages at the right time, it's useful, but if it engages erroneously it can be dangerous. If you're getting lots of rewinds while the server is underway with a relatively low CPU load, you might want to check out what David H. from Canonical has
[pulseaudio-discuss] pulseaudio
Try to test the new xubuntu 11.04 with kde on a multi-user system. The first user (for example user1) can log in and gets a default sink from pulse. The second user(for example user2) that will log in gets a auto_null because pulse did not found any sinks. If i log out user1, than user2 can get a default sink by kill and start pulse. Where should be the reason? gd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] crackle and stutter
On 11-04-12 12:00 PM, Sean McNamara wrote: Hi, Hi, Can you give an example of what application(s) in particular trigger this? Skype for example, when somebody sends an IM, or logs on. Skype pops up a notification and emits a sound event. Or when I generate a keyboard sound event, like hitting tab a bunch of times at a bash prompt. It displays: Display all 5014 possibilities? (y or n) For example, and each tab emits a sound event. If I hit tab a good number of times I can see this in PA: D: core-scache.c: Playing sample bell-window-system on alsa_output.pci-_00_10.1.analog-stereo D: memblockq.c: memblockq requested: maxlength=17640, tlength=0, base=2, prebuf=1, minreq=1 maxrewind=0 D: memblockq.c: memblockq sanitized: maxlength=17640, tlength=17640, base=2, prebuf=2, minreq=2 maxrewind=0 D: module-stream-restore.c: Not restoring device for stream sink-input-by-media-role:event, because already set to 'alsa_output.pci-_00_10.1.analog-stereo'. D: module-intended-roles.c: Not setting device for stream bell-window-system, because already set. I: module-stream-restore.c: Restoring volume for sink input sink-input-by-media-role:event. I: module-stream-restore.c: Restoring mute state for sink input sink-input-by-media-role:event. D: module-suspend-on-idle.c: Sink alsa_output.pci-_00_10.1.analog-stereo becomes busy. I: resampler.c: Forcing resampler 'copy', because of fixed, identical sample rates. D: resampler.c: Channel matrix: D: resampler.c:I00 D: resampler.c: +-- D: resampler.c: O00 | 1.000 D: resampler.c: O01 | 1.000 I: remap_sse.c: Using SSE mono to stereo remapping I: resampler.c: Using resampler 'copy' I: resampler.c: Using s16le as working format. D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=4, prebuf=0, minreq=1 maxrewind=0 D: memblockq.c: memblockq sanitized: maxlength=33554432, tlength=33554432, base=4, prebuf=0, minreq=4 maxrewind=0 I: sink-input.c: Created input 6004 bell-window-system on alsa_output.pci-_00_10.1.analog-stereo with sample spec s16le 1ch 44100Hz and channel map mono I: sink-input.c: media.name = bell-window-system I: sink-input.c: event.id = bell-window-system I: sink-input.c: media.role = event I: sink-input.c: application.process.id = 3904 I: sink-input.c: application.name = gnome-terminal I: sink-input.c: event.description = Bell event I: sink-input.c: media.filename = /usr/share//sounds/ubuntu/stereo/bell.ogg I: sink-input.c: native-protocol.peer = UNIX socket client I: sink-input.c: native-protocol.version = 16 I: sink-input.c: window.x11.display = :0.0 I: sink-input.c: window.x11.screen = 0 I: sink-input.c: application.process.user = brian I: sink-input.c: application.process.host = pc I: sink-input.c: application.process.binary = metacity I: sink-input.c: application.language = en_CA.UTF-8 I: sink-input.c: application.process.machine_id = c5af5645621daea8981bd8ac95e82500 I: sink-input.c: application.process.session_id = c5af5645621daea8981bd8ac95e82500-1301933908.840922-406521422 I: sink-input.c: window.x11.xid = 48333716 I: sink-input.c: window.name = pc:/etc/shorewall6/gw-new I: sink-input.c: module-stream-restore.id = sink-input-by-media-role:event D: core-util.c: posix_madvise() worked fine! D: alsa-sink.c: Requested to rewind 352768 bytes. D: alsa-sink.c: Limited to 21016 bytes. D: alsa-sink.c: before: 5254 D: alsa-sink.c: after: 5254 D: alsa-sink.c: Rewound 21016 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: source.c: Processing rewind... D: alsa-sink.c: Latency set to 136.00ms D: alsa-sink.c: hwbuf_unused=328780 D: alsa-sink.c: setting avail_min=83952 D: alsa-sink.c: Requested to rewind 352768 bytes. D: alsa-sink.c: Limited to 23660 bytes. D: alsa-sink.c: before: 5915 D: alsa-sink.c: after: 5915 D: alsa-sink.c: Rewound 23660 bytes. I:
Re: [pulseaudio-discuss] pulseaudio
Hi, On Tue, Apr 12, 2011 at 12:15 PM, duportail po...@telenet.be wrote: Try to test the new xubuntu 11.04 with kde on a multi-user system. The first user (for example user1) can log in and gets a default sink from pulse. The second user(for example user2) that will log in gets a auto_null because pulse did not found any sinks. If i log out user1, than user2 can get a default sink by kill and start pulse. Where should be the reason? This is the classic multi-user problem: you're using a soundcard without hardware mixing, so only one ALSA application can take direct control of the hardware device at a time. user1's pulseaudio daemon takes control of it, so obviously user2's PA daemon will just get Device or resource busy when trying to snd_pcm_open() on hw:0 (for example). This problem has existed since ALSA existed. There's no direct fix without scrapping the API and rewriting it. I guess there is no solution yet (still) in 11.04, but you can see that folks in the Ubuntu community are trying to resolve the issue with a number of possible approaches: https://wiki.edubuntu.org/BluePrints/multiuser-soundcards-pulseaudio Running as system-wide is one possible approach... http://www.pulseaudio.org/wiki/SystemWideInstance Not sure if there's yet a solution allowing the use of shm and module-native-protocol-unix for multiple users (this is ideally what you'd want for maximum performance / minimum latency), but it's quite easy to set up module-native-protocol-tcp and connect to localhost using the `default-server' parameter in client.conf, at the cost of latency. Let me know if you need more details on this particular approach. BTW, search the archives of this list at gmane http://blog.gmane.org/gmane.comp.audio.pulseaudio.general -- there are many many historical posts about multi-user setups. Sean gd ___ 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] pulseaudio
Op 12-4-2011 18:30, Sean McNamara schreef: Hi, On Tue, Apr 12, 2011 at 12:15 PM, duportailpo...@telenet.be wrote: Try to test the new xubuntu 11.04 with kde on a multi-user system. The first user (for example user1) can log in and gets a default sink from pulse. The second user(for example user2) that will log in gets a auto_null because pulse did not found any sinks. If i log out user1, than user2 can get a default sink by kill and start pulse. Where should be the reason? This is the classic multi-user problem: you're using a soundcard without hardware mixing, so only one ALSA application can take direct control of the hardware device at a time. user1's pulseaudio daemon takes control of it, so obviously user2's PA daemon will just get Device or resource busy when trying to snd_pcm_open() on hw:0 (for example). This problem has existed since ALSA existed. There's no direct fix without scrapping the API and rewriting it. I guess there is no solution yet (still) in 11.04, but you can see that folks in the Ubuntu community are trying to resolve the issue with a number of possible approaches: https://wiki.edubuntu.org/BluePrints/multiuser-soundcards-pulseaudio Running as system-wide is one possible approach... http://www.pulseaudio.org/wiki/SystemWideInstance Not sure if there's yet a solution allowing the use of shm and module-native-protocol-unix for multiple users (this is ideally what you'd want for maximum performance / minimum latency), but it's quite easy to set up module-native-protocol-tcp and connect to localhost using the `default-server' parameter in client.conf, at the cost of latency. Let me know if you need more details on this particular approach. BTW, search the archives of this list at gmane http://blog.gmane.org/gmane.comp.audio.pulseaudio.general -- there are many many historical posts about multi-user setups. Sean gd ___ 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 Sorry, forgot to mention: there multiple (two) usb soundcards on the system.It is working good on xubuntu 10.10. As you said, the second user gets a Device or resource busy.When I logout the first user, the second user can get a default sink. gd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] crackle and stutter
On Tue, Apr 12, 2011 at 12:24 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: On 11-04-12 12:00 PM, Sean McNamara wrote: Hi, Hi, Can you give an example of what application(s) in particular trigger this? Skype for example, when somebody sends an IM, or logs on. Skype pops up a notification and emits a sound event. Or when I generate a keyboard sound event, like hitting tab a bunch of times at a bash prompt. It displays: Display all 5014 possibilities? (y or n) For example, and each tab emits a sound event. If I hit tab a good number of times I can see this in PA: D: core-scache.c: Playing sample bell-window-system on alsa_output.pci-_00_10.1.analog-stereo D: memblockq.c: memblockq requested: maxlength=17640, tlength=0, base=2, prebuf=1, minreq=1 maxrewind=0 D: memblockq.c: memblockq sanitized: maxlength=17640, tlength=17640, base=2, prebuf=2, minreq=2 maxrewind=0 D: module-stream-restore.c: Not restoring device for stream sink-input-by-media-role:event, because already set to 'alsa_output.pci-_00_10.1.analog-stereo'. D: module-intended-roles.c: Not setting device for stream bell-window-system, because already set. I: module-stream-restore.c: Restoring volume for sink input sink-input-by-media-role:event. I: module-stream-restore.c: Restoring mute state for sink input sink-input-by-media-role:event. D: module-suspend-on-idle.c: Sink alsa_output.pci-_00_10.1.analog-stereo becomes busy. I: resampler.c: Forcing resampler 'copy', because of fixed, identical sample rates. D: resampler.c: Channel matrix: D: resampler.c: I00 D: resampler.c: +-- D: resampler.c: O00 | 1.000 D: resampler.c: O01 | 1.000 I: remap_sse.c: Using SSE mono to stereo remapping I: resampler.c: Using resampler 'copy' I: resampler.c: Using s16le as working format. D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=4, prebuf=0, minreq=1 maxrewind=0 D: memblockq.c: memblockq sanitized: maxlength=33554432, tlength=33554432, base=4, prebuf=0, minreq=4 maxrewind=0 I: sink-input.c: Created input 6004 bell-window-system on alsa_output.pci-_00_10.1.analog-stereo with sample spec s16le 1ch 44100Hz and channel map mono I: sink-input.c: media.name = bell-window-system I: sink-input.c: event.id = bell-window-system I: sink-input.c: media.role = event I: sink-input.c: application.process.id = 3904 I: sink-input.c: application.name = gnome-terminal I: sink-input.c: event.description = Bell event I: sink-input.c: media.filename = /usr/share//sounds/ubuntu/stereo/bell.ogg I: sink-input.c: native-protocol.peer = UNIX socket client I: sink-input.c: native-protocol.version = 16 I: sink-input.c: window.x11.display = :0.0 I: sink-input.c: window.x11.screen = 0 I: sink-input.c: application.process.user = brian I: sink-input.c: application.process.host = pc I: sink-input.c: application.process.binary = metacity I: sink-input.c: application.language = en_CA.UTF-8 I: sink-input.c: application.process.machine_id = c5af5645621daea8981bd8ac95e82500 I: sink-input.c: application.process.session_id = c5af5645621daea8981bd8ac95e82500-1301933908.840922-406521422 I: sink-input.c: window.x11.xid = 48333716 I: sink-input.c: window.name = pc:/etc/shorewall6/gw-new I: sink-input.c: module-stream-restore.id = sink-input-by-media-role:event D: core-util.c: posix_madvise() worked fine! D: alsa-sink.c: Requested to rewind 352768 bytes. D: alsa-sink.c: Limited to 21016 bytes. D: alsa-sink.c: before: 5254 D: alsa-sink.c: after: 5254 D: alsa-sink.c: Rewound 21016 bytes. D: sink.c: Processing rewind... D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: sink-input.c: Have to rewind 21016 bytes on render memblockq. D: source.c: Processing rewind... D: alsa-sink.c: Latency set to 136.00ms D: alsa-sink.c: hwbuf_unused=328780 D: alsa-sink.c: setting avail_min=83952 D: alsa-sink.c:
Re: [pulseaudio-discuss] pulseaudio
On Tue, 2011-04-12 at 12:30 -0400, Sean McNamara wrote: Hi, On Tue, Apr 12, 2011 at 12:15 PM, duportail po...@telenet.be wrote: Try to test the new xubuntu 11.04 with kde on a multi-user system. The first user (for example user1) can log in and gets a default sink from pulse. The second user(for example user2) that will log in gets a auto_null because pulse did not found any sinks. If i log out user1, than user2 can get a default sink by kill and start pulse. Where should be the reason? This is the classic multi-user problem: you're using a soundcard without hardware mixing, so only one ALSA application can take direct control of the hardware device at a time. user1's pulseaudio daemon takes control of it, so obviously user2's PA daemon will just get Device or resource busy when trying to snd_pcm_open() on hw:0 (for example). This problem has existed since ALSA existed. There's no direct fix without scrapping the API and rewriting it. Actually, this situation is supposed to be handled just fine (unless duportail expects both users to be able to use the audio hw simultaneously, which he doesn't mention). If this doesn't work, xubuntu is broken. Some things that can cause this problem: the users are in the audio group, consolekit isn't running or consolekit's udev-acl isn't in use. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] crackle and stutter
On 11-04-12 12:52 PM, Sean McNamara wrote: I can't tell from your PA logs which soundcard you are using to play back notifications and rhythmbox sound? 0 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfe024000 irq 22 Yes, this one. or 1 [U0x46d0x8c5]: USB-Audio - USB Device 0x46d:0x8c5 USB Device 0x46d:0x8c5 at usb-:00:0b.1-3, high speed This is a webcam with only a mic on it. [ 14.160524] hda_intel: Disable MSI for Nvidia chipset ... [691084.544026] hda_codec: invalid CONNECT_LIST verb 12[2]:2100 [691120.324230] hda_codec: invalid CONNECT_LIST verb 12[2]:2100 [691203.712806] hda_codec: invalid CONNECT_LIST verb 12[2]:2100 [691277.537037] hda_codec: invalid CONNECT_LIST verb 12[2]:2100 Last one was there was at Apr 12 12:17:46. Hmm. Can you correlate PulseAudio is dropping out with one of these messages? 691277 seconds after startup would be 8 days and some minutes after kernel init, so it seems recent? There is no correlation unfortunately. I just had a dropout and no new messages of that nature. b. signature.asc Description: OpenPGP digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio
Op 12-4-2011 18:53, Tanu Kaskinen schreef: On Tue, 2011-04-12 at 12:30 -0400, Sean McNamara wrote: Hi, On Tue, Apr 12, 2011 at 12:15 PM, duportailpo...@telenet.be wrote: Try to test the new xubuntu 11.04 with kde on a multi-user system. The first user (for example user1) can log in and gets a default sink from pulse. The second user(for example user2) that will log in gets a auto_null because pulse did not found any sinks. If i log out user1, than user2 can get a default sink by kill and start pulse. Where should be the reason? This is the classic multi-user problem: you're using a soundcard without hardware mixing, so only one ALSA application can take direct control of the hardware device at a time. user1's pulseaudio daemon takes control of it, so obviously user2's PA daemon will just get Device or resource busy when trying to snd_pcm_open() on hw:0 (for example). This problem has existed since ALSA existed. There's no direct fix without scrapping the API and rewriting it. Actually, this situation is supposed to be handled just fine (unless duportail expects both users to be able to use the audio hw simultaneously, which he doesn't mention). If this doesn't work, xubuntu is broken. Some things that can cause this problem: the users are in the audio group, consolekit isn't running or consolekit's udev-acl isn't in use. Maybe xubuntu is broken.I will wait until further releases gd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
Jack detect does not use the ALSA kernel subsystem but does instead use the input subsystem for jack status. It makes sense to create a new module so we can then use jack detect for non ALSA sound devices. I'm a bit lost here. What are 'non ALSA sound devices'? And to the best of my knowledge these events are only generated by ALSA drivers... Am I missing something here? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio
'Twas brillig, and duportail at 12/04/11 19:20 did gyre and gimble: Op 12-4-2011 18:53, Tanu Kaskinen schreef: On Tue, 2011-04-12 at 12:30 -0400, Sean McNamara wrote: Hi, On Tue, Apr 12, 2011 at 12:15 PM, duportailpo...@telenet.be wrote: Try to test the new xubuntu 11.04 with kde on a multi-user system. The first user (for example user1) can log in and gets a default sink from pulse. The second user(for example user2) that will log in gets a auto_null because pulse did not found any sinks. If i log out user1, than user2 can get a default sink by kill and start pulse. Where should be the reason? This is the classic multi-user problem: you're using a soundcard without hardware mixing, so only one ALSA application can take direct control of the hardware device at a time. user1's pulseaudio daemon takes control of it, so obviously user2's PA daemon will just get Device or resource busy when trying to snd_pcm_open() on hw:0 (for example). This problem has existed since ALSA existed. There's no direct fix without scrapping the API and rewriting it. Actually, this situation is supposed to be handled just fine (unless duportail expects both users to be able to use the audio hw simultaneously, which he doesn't mention). If this doesn't work, xubuntu is broken. Some things that can cause this problem: the users are in the audio group, consolekit isn't running or consolekit's udev-acl isn't in use. Maybe xubuntu is broken.I will wait until further releases Make sure that ck-list-sessions reports correctly that only the active user is actually active. Also check the user groups as Tanu reported. But all in all, this *should* be handled correctly (and certainly is on other systems) 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
Re: [pulseaudio-discuss] rygel mediaserver
I think you have to load module-protocol-http as well (not sure I've got the name totally correct). That's the one I meant when I said I have also enabled the http-tcp module, - it's called module-http-protocol-tcp I tried it with my PS3 but never got very far (it defo did try to talk to the http module tho') If you get it working with your WDTV box just by loading http protocol, please report back and I'll tweak paprefs. No such luck. Running pa in a console it says: I: socket-server.c: TCP connection accepted by tcpwrap. I: client.c: Created 12 HTTP client (TCP/IP client from 192.168.178.99:41994) I: client.c: Freed 12 HTTP client (TCP/IP client from 192.168.178.99:41994) immediately, and the WDTV says unable to play the selected file. With my LG HB405SU there is on such message, but rygel says: ** (rygel:10171): WARNING **: rygel-http-request.vala:91: Invalid seek request When I try to play the stream. Cheers, - Gunnar ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense
On Tue, Apr 12, 2011 at 02:14:04PM -0500, pl bossart wrote: Jack detect does not use the ALSA kernel subsystem but does instead use the input subsystem for jack status. It makes sense to create a new module so we can then use jack detect for non ALSA sound devices. I'm a bit lost here. What are 'non ALSA sound devices'? And to the best of my knowledge these events are only generated by ALSA drivers... Am I missing something here? These events can be generated by anything - prior to my implementing the ALSA support for this all the implementations in mainline were doing this via the gpio-keys driver since they were detecting a microswitch in the jack. I'd expect that non-audio jacks may also end up reporting via the same interface (video for example), but I'm not sure if Pulse would be interested in anything non-ALSA. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
