Re: [pulseaudio-discuss] Fighting rewinds / pulseaudio crash - update
Thanks for the update David :) 'Twas brillig, and David Henningsson at 31/01/11 05:07 did gyre and gimble: So to recap a little on the fighting rewinds issue - the one that makes pulseaudio crash due to spending too much time in RT prio, and with the pulseaudio log filled with rewinds. A month ago I provided five patches in total, two in gstreamer[1] and three in pulseaudio. GStreamer #1: we have the don't start the stream until we have written some samples - this fix is in gstreamer HEAD, committed by Wim Taymans. GStreamer #2: send larger packages by removing a strange limit to gstreamer's segment size. This fix has been posted to the gstreamer-devel mailinglist, but not committed AFAIK. I'm attaching a version of the patch which has proper git headers and against git head. Both GStreamer fixes have recently been uploaded to Ubuntu Natty, the development version of Ubuntu. OK, I'll try and do the same in mdv once I can actually get my system in a vaguely working state due to all the changes of late... (rpm5 switch). PulseAudio #1 and #2: I believe these should be applied to PulseAudio upstream. OK, I think you've given it sufficient testing and exposer to confirm this. Can I just ask if these are safe if the corresponding gst fixes are not committed? (i.e. will GST generally bork or should it cope as well as currently without it's patches?) Also, master only or master+s-q (I'm personally favouring the latter). PulseAudio #3: A person with alias h31 helped out here, and noticed this patch was the one causing a regression in Skype. While I haven't exactly figured out why, I do notice that this patch could cause problems for very short samples. So let's drop this one for the time being. OK, I can ask my Skype contact to see if there is something we can do to debug this further. Just ping me to discuss and we can take it from there. For reference I resend the three patches (one in GStreamer, two in pulseaudio) that I would like to see applied. Cool. 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] State of various rate adjustment patches
'Twas brillig, and Maarten Bosmans at 31/01/11 10:36 did gyre and gimble: 2011/1/16 Maarten Bosmans mkbosm...@gmail.com: The branch is up at https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment ready for merging, as far a I am concerned. I'm still not entirely sure whether the change of https://github.com/mkbosmans/pulseaudio/commit/72b90ea8ac53e23862284991a2ce355de250f585 is correct, but it seems to avoid unnecessary rewinds for me. I've tested module-loopback by playing to a null-sink and looping its monitor to the real alsa sink. This showed good behaviour, but may be the algorithm I used for module-rtp-recv should also be used here. Does anyone has a better suggestion for a setup to test module-loopback? null-sink and alsa have very stable latencies, so its no good test for module-loopback. There where no objections on the list, so I guess the branch at https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment can be merged with master. Cool, thanks Maaren. I'll pull in David's changes and then yours. I'll be away for a week now (skiing trip in Switserland, yay), so I'am able to answer any questions later. I'll be away in France next week doing much the same! Enjoy! 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] Fighting rewinds / pulseaudio crash - update
'Twas brillig, and David Henningsson at 31/01/11 10:46 did gyre and gimble: On 2011-01-31 10:41, Colin Guthrie wrote: Thanks for the update David :) You're welcome :-) PulseAudio #1 and #2: I believe these should be applied to PulseAudio upstream. OK, I think you've given it sufficient testing and exposer to confirm this. Can I just ask if these are safe if the corresponding gst fixes are not committed? (i.e. will GST generally bork or should it cope as well as currently without it's patches?) Both are optimisations - gst patch only will be better than no patch at all, and PA patch only will be better than no patch at all. Most people will see it solved by either patch, but I guess that there are machines so slow that you'll need both. No worries, just wanted to make sure that it wasn't a paired updated - e.g. the PA commits *required* the GST ones (I figured it was very unlikely but with the Skype issue on the third patch, I figured I'd be safer ask!) Also, master only or master+s-q (I'm personally favouring the latter). Me too. OK, applied to my tree now with a tiny modification due to Lennart's rate limit patch on s-q which I've now merged to master (with updates for additional calls). Will push once I've done a few more bits and bobs. 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] Fighting rewinds / pulseaudio crash - update
On 2011-01-31 12:41, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 31/01/11 10:46 did gyre and gimble: On 2011-01-31 10:41, Colin Guthrie wrote: Thanks for the update David :) You're welcome :-) PulseAudio #1 and #2: I believe these should be applied to PulseAudio upstream. OK, I think you've given it sufficient testing and exposer to confirm this. Can I just ask if these are safe if the corresponding gst fixes are not committed? (i.e. will GST generally bork or should it cope as well as currently without it's patches?) Both are optimisations - gst patch only will be better than no patch at all, and PA patch only will be better than no patch at all. Most people will see it solved by either patch, but I guess that there are machines so slow that you'll need both. No worries, just wanted to make sure that it wasn't a paired updated - e.g. the PA commits *required* the GST ones (I figured it was very unlikely but with the Skype issue on the third patch, I figured I'd be safer ask!) Also, master only or master+s-q (I'm personally favouring the latter). Me too. OK, applied to my tree now with a tiny modification due to Lennart's rate limit patch on s-q which I've now merged to master (with updates for additional calls). Will push once I've done a few more bits and bobs. Thanks :-) This, and that Takashi agreed to take my ALSA patch in 2.6.38 as well (totally unrelated), this might actually turn out to be a really good day! :-) -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Problems running pulseaudio on Slackware based system
Is it possible the issue starts from rc.alsa script which stores some info in a file asound.state? Also notice, that if I disable rc.alsa script, delete asound.state seems to work everything, but by default the speakers on the laptop are on mute so with alsamixer I have to enable them. How could I fix that?! On Mon, Jan 31, 2011 at 18:54, pl bossart bossart.nos...@gmail.com wrote: Jan 28 20:32:01 kongoni pulseaudio[2504]: module-alsa-card.c: Failed to find a working profile. Jan 28 20:32:01 kongoni pulseaudio[2504]: module.c: Failed to load module module-alsa-card (argument: device_id=29 name=platform-thinkpad_acpi I am getting the same errors on a Thinkpad W500. It doesn't look like it has any impact on the sound. If I mmod thinkpad_acpi the audio outputs work just fine -Pierre ___ 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] Flat volumes and restoring the app volume
On Mon, 2011-01-31 at 22:27 +0300, Gregory Petrosyan wrote: On Mon, Jan 31, 2011 at 1:45 PM, Colin Guthrie gm...@colin.guthr.ie wrote: ... Thanks a lot for the explanation! I am asking these, because I've managed to make an app restore the volume properly using ext-stream-restore.h, but when I turn the flat volume on, behaviour is counter-intuitive to say at least. Can you elaborate on this a little? When you say you've manage to make an app restore the volume properly using ext-stream-restore.h what do you mean? Do you mean you are making an editor for the stream restore database or are you just meaning that you have an audio producing app and you are manually using ext-stream-restore.h to get it's saved volume and are doing something with it manually to set it's own volume? If the latter, don't do that, the server handles all that for you automatically. If the former then cool. I have an audio player, and I want it to a) save/restore the volume on shutdown/startup b) be able to show the future volume and modify it after the startup, but before the playback b) is a problem: I either have to have stream open all the time (but I can't do that since I do not know the sample format before the start of the playback, so I can't create a stream beforehand), or to manually read/write the m-s-r database. It seems that, unfortunately, it is almost impossible to make such a basic functionality work with PA, if using flat volumes. Because when using m-s-r database + flat volumes, although the real volume remains the same after the restart, e.g. displayed volume is wrong. Here's an example: (app | system) 60% | 100% [decrease the system volume] 31% | ~50% [restart the app, do not start the playback] 60% | ~50% (60% is more or less what is in the m-s-r database I assume) [start the playback] 31% | ~50% (finally, displayed volume is correct) As I explained in my previous mail (I didn't notice before hitting send that you already sent this message), m-s-r works with decibels, and while the stream is not playing, you can calculate the new volume by taking the current sink volume in decibels and subtracting from that the amount of attenuation stored in the m-s-r database. There's just one problem, this doesn't actually work reliably, because you don't what the current sink volume is, because there's no concept of current sink while you're not playing anything. So, it's true that it's almost impossible to implement the basic functionality of showing the future volume in a media player while not playing anything. You could achieve something that is quite reliable in practice, though: read also the saved device of the same stream-restore entry that you're reading the volume from. If there's no saved device, use the default sink (see pa_context_get_server_info()). Before doing that, however, I would like to hear why you need to show the future volume. So that the user can set the volume higher or lower before starting playback? Why is the system volume inadequate for doing that? What is the use case where the user wants to turn up or down the music player volume before hearing anything, and only the music player volume, not any other application? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Flat volumes and restoring the app volume
'Twas brillig, and Tanu Kaskinen at 31/01/11 20:48 did gyre and gimble: Before doing that, however, I would like to hear why you need to show the future volume. So that the user can set the volume higher or lower before starting playback? Why is the system volume inadequate for doing that? What is the use case where the user wants to turn up or down the music player volume before hearing anything, and only the music player volume, not any other application? I would also say that players such as Totem just grey out the volume icon when nothing is playing which seems like a fairly simple solution to the problem but I totally understand if you don't like that. When Tanu suggested reading the device from m-s-r too, this is a reasonable solution *as currently implemented*, but it is highly likely that m-s-r will undergo some changes in the not too distant future to deal with priority lists - e.g. rather than an application just saving one device, it would actually save a whole bunch, in order of preference. If the highest priority device is not available it will fall back to the next one and so on until it finds and available device (the reasons for devices not being available would include, disconnected network or bluetooth devices, unplugged USB etc.) Add to that, we'll probably save this priority list for categories of applications primarily (although support for individual apps will still be kept). So all in all the whole routing logic will become more complex and not just a simple matter of reading the saved device from m-s-r. So I would prefer if you could do either: 1. Just grey out the volume until the stream is connected. or 2. Very quickly connect a corked stream, read the volume and then disconnect the stream again. (I think the latter would work, but I've not thought too hard about it). 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] [HS] Wich linux library to decode MP3 ?
Hello, 'Twas brillig, and Serge SMEESTERS at 31/01/11 20:13 did gyre and gimble: This week-end, FOSDEM at Brxelles... I plane to meet you to show my code. I'm afraid I'm not personally going to get to FOSDEM. Not really sure who from this community is going. I presume Lennart will but not 100% sure. I'm sure people can say on this list tho' if they'll be there! My code use vorbis only for now and I hope to quickly code mp3 play feature... Wich lib should I use for that ? I don't really know. GStreamer is a good optionf or the full pipeline but that's probably not the point in your app libmad should work but it's also perhaps worth looking at ffmpeg. But I'm no expert here I'm afraid. 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
