Re: [pulseaudio-discuss] rtkit: add pid as argument
Maarten Lankhorst wrote: Well, the use case would be wine's wineserver. On windows programs usually set audio threads to THREAD_PRIORITY_TIME_CRITICAL to indicate that they have to have a certain priority. But in windows thread handles are global, so doing it inside wine's 'ntdll' library wouldn't make much sense, since the request to set the priority would go to wineserver first, since there's no way to tell from inside a wine program to tell which handle corresponds to the thread, or even if that handle is local or not. Wineserver controls this information so all requests that involve handles involve a wineserver call, in general. So racing cannot happen, because wineserver is the only one making the requests. Just a question, what about RLIMIT_RTTIME, which rtkit requires to be set for enabling rt? AFAIK there is no equivalent in Windows. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rtkit: add pid as argument
On Sun, 25.04.10 21:41, David Henningsson (launchpad@epost.diwic.se) wrote: which handle corresponds to the thread, or even if that handle is local or not. Wineserver controls this information so all requests that involve handles involve a wineserver call, in general. So racing cannot happen, because wineserver is the only one making the requests. Just a question, what about RLIMIT_RTTIME, which rtkit requires to be set for enabling rt? AFAIK there is no equivalent in Windows. Well, we enforce RLIMIT_RTTIME mostly because we can, not because it would really inhibit all kind of RT-related misbehaviour of the clients. Or in other words: RLIMIT_RTTIME is quite useful as a protection against programming errors somewhre, however it is still easily circumventable by people who really try to do evil things, unless combined with other tricks, such as SCHED_RESET_ON_FORK. 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
[pulseaudio-discuss] Left/right volume unlinked in hardware?
Hi list, When I adjust the volume in PulseAudio, I noticed that the volume for my left speaker is being reduced more than the volume of my right speaker. The difference is small, but annoying enough when using headphones. So I set out to investigate with alsamixer and found that PA always prefers scaling the Front volume control. When I set this control to 100%, everything sounds fine, but reducing it does indeed introduce the difference I mentioned above, even if the volumes are linked in alsamixer. Other volume controls such as Master Front, PCM etc seem to be unaffected. So as a workaround, I start up mplayer, pause it and set it to 100% volume in PA, which forces software gain control. I don't think this is an ALSA problem? ALSA just simply interfaces all those volume controls to the user and can't help if some of them are broken. Since PulseAudio takes control of setting the levels, I think it's also PA's responsibilty to also know about such hardware quirks? I assume that I'm not the first person to find a problem with a hw mixer control, but I couldn't find any such quirk databases in PulseAudio source tree. lspci -nn: 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383] aplay -l: card 0: SB [HDA ATI SB], device 0: VT1708B Analog [VT1708B Analog] Subdevices: 1/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 card 0: SB [HDA ATI SB], device 1: VT1708B Digital [VT1708B Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 Regards, Marti ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
