from:"Lennart Poettering"

On Wed, 19.05.10 01:00, David Henningsson (launchpad@epost.diwic.se) wrote:

Heya,

 Sometimes the input device shows up at device ID 0, and sometimes device
 ID 1, so try both.

Humpf. Why is that so? The driver authors presumably have a reason for
this assignment, and before we merge something like this we should
figure out what's going on and how we should label this. We currently
label that mapping Analog Streo Channel A. It appears to me that that
mapping label might not be accurate anymore after such a change.

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] Assertion failure with a fake/null sink set to 5.1 channels

On Sat, 22.05.10 00:11, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 Hi,
 
 This isn't really a bug report but I need somewhere to dump this so
 I don't forget :)
 
 This happened with a fake null sink (pactl load-module
 module-null-sink sink_name=fake51 channels=6 
 channel_map=front-left,front-right,center,rear-left,rear-right,lfe),
 pavucontrol, split the channels and then update the volume of one of
 the channels.
 
 I'll try and reproduce properly via a debugger at some point soon,
 but for the sake of documenting it happened, here is the log :p

Please file a bug and include a bt! 

Thanks,

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] 0pointer.de bogon filters

On Wed, 19.05.10 15:41, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 
 'Twas brillig, and Lennart Poettering at 19/05/10 15:16 did gyre and gimble:
 On Wed, 19.05.10 07:20, Neil Wilson (n...@aldur.co.uk) wrote:
 
 Forgive me for spamming the list, but it seems that the bogon
 filtering on your site (or upstream provider) may be out of date. I
 can't get to it from the 2.99.x.x address my ISP has given me, which
 is a newly allocated RIPE block.
 
 filtering as in rbl/dns balcklists or as in firewall?
 
 We run no firewall on the machine, and the rbls are normal rbls with no
 local configuration, so if there's a problem, then there is a problem
 with the provider or the rbl people.
 
 It's a list of IP ranges that are to be ignored in the DNS setup.
 The list generally gets included in the named.conf file.

In which form? My own server does not have a list like that. I see no
configuration for anything like that. I certainly didn't configure it
like that and I am kinda sure something like this is not configured in
the defaults either.

 As the nameservers are ns.0pointer.de and some other one, the
 outdated list could be on your server and/or on ns10.schlundtech.de.

Hmm, looks like a problem of the latter DNS server then.

Neil, if you ask ns.0pointer.de directly, do you have problems like this
too? If not, could you please ping the ns10.schlundtech.de folks instead?

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] module_combine arguments 0.9.21

On Tue, 18.05.10 20:47, Jim Duda (j...@duda.tzo.com) wrote:

 Can someone tell me if the arguments for module_combine have changed recently?
 
 These no longer work with 0.9.21, but did with the earlier release with fc11 
 (0.9.15 I believe).
 
 load-module module-combine sink_name=combined master=alsa_output.hw_AudioPCI 
 slaves=alsa_output.hw_ICH5,rtp,sphinx_playback
 load-module module-combine sink_name=combined_local 
 master=alsa_output.hw_AudioPCI slaves=alsa_output.hw_ICH5

BTW, the wiki tends to be out of date. The recommended way to figure out
the parameters is this:

$ pulseaudio --dump-modules module-combine

It's terse, but complete.

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] Help with Udev Please

On Tue, 18.05.10 19:34, Jim Duda (j...@duda.tzo.com) wrote:

 I just upgraded from fc11 to fc12.  With fc12 comes PA 0.9.21.
 
 Pulseaudio fails to detect any of my audio cards, I have two cards.
 
 I'm positive the problem is with UDEV.  When I boot the system, 
 I'm getting a cryptic message from udev about some {ATTR ... uvent} 

Plase provide a longer output. Are you sure this is related ot PA?

 file not found.  I'm having trouble getting the error message to 
 report, it flies off the screen before I can record it.

C-s/C-q is your friend.

 I'm looking for advice on may be how best to debug how udev deals
 with audio cards?  Maybe someone has already seen this issue?

we just enumerate them via udev. The output of pulseaudio -v
should tell you everything.

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] 0pointer.de bogon filters

2010-05-19 Thread Lennart Poettering

On Wed, 19.05.10 07:20, Neil Wilson (n...@aldur.co.uk) wrote:

 Forgive me for spamming the list, but it seems that the bogon
 filtering on your site (or upstream provider) may be out of date. I
 can't get to it from the 2.99.x.x address my ISP has given me, which
 is a newly allocated RIPE block.

filtering as in rbl/dns balcklists or as in firewall?

We run no firewall on the machine, and the rbls are normal rbls with no
local configuration, so if there's a problem, then there is a problem
with the provider or the rbl people.

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] rtkit: add pid as argument

2010-05-08 Thread Lennart Poettering

On Sat, 08.05.10 11:21, Maarten Lankhorst (m.b.lankho...@gmail.com) wrote:

  So let my rephrase my question to Maarten: Since there is no equivalent
  to RLIMIT_RTTIME in Windows, applications might assume they can run in
  RT for extended periods of time. This might be considered bad
  application behavior in any operating system, but nonetheless - do we
  risc regressions when these applications are being killed, instead of
  the previous behavior which just let them run in non-RT?
 I don't think this will happen, if it is going to I will handle
 SIGXCPU in wine, and just demote all realtime threads back to normal
 priority when that signal is sent by the kernel.

RLIMIT_RTTIME elapsing triggers a SIGKILL, not a SIGXCPU,
unfortunately. (And SIGKILL you cannot catch)

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] 24 bit sound

On Fri, 07.05.10 00:22, David Björkevik (da...@bjorkevik.se) wrote:

 Dear list,
 
 I'm in the process of buying a new soundcard. For a little more money I
 can get a 24-bit one, which I figure would be nice for things like
 software mixing.
 
 However, I can't find anything on how PulseAudio handles audio above 16
 bit / 48KHz. Will my 24-bit upgrade be lost in software?
 
 Also, what about higher frequencies, 96KHz and upwards?

As the others already mentioned, PA should be able to deal with both
higher freqs and bit depths just fine. However, given that most material
you could play is not 24bit nor 96khz the effect of running PA like this
will be mostly that the CPU usage goes up, since we then need to
reformat/resample everything you play.

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] rtkit: add pid as argument

On Wed, 05.05.10 01:10, Maarten Lankhorst (m.b.lankho...@gmail.com) wrote:

 Patch looks goot to me. But could you fix one thing: I think
 MakeThreadRealtimeWithPID() (or something like tht) would be a better
 name than MakeThreadRealtime2(). After examples like wait(), wait3() and
 wait4() in Linux, I cannot say I am a big fan of numbering function
 calls. ;-)
 Ok, renamed them to WithPID with a sed, and tested in wine just to
 be sure. :)

Thanks. Applied. Will do a new release shortly.

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] [ANNOUNCE] RealtimeKit 0.7

Heya!

http://0pointer.de/public/rtkit-0.7.tar.gz

David Henningsson (1):
  rtkit: Add client-side testing of properties

Jirka Klimes (1):
  Fix spelling of 'Successfully'

Lennart Poettering (1):
  build-sys: prepare 0.7 release

Luke Yelavich (1):
  Add rtkitctl manpage

Maarten Lankhorst (1):
  Add WithPID functions to allow setting scheduler remotely

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] Anyone seen this problem: Cards show up but their sinks/sources do not.

On Mon, 03.05.10 09:03, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 Hi,
 
 I come across this occasionally (usually when moving from home to my
 office where I have a USB speaker via a USB Hub.
 
 The card itself is shown fine and lets me choose the profiles etc., but
 it refuses to actually load any sinks/source for it.
 
 Changing profile doesn't seem to help kick it into gear and restarting
 PA is the only possible answer.
 
 I suspect it's something odd relating to not unloading properly which in
 turn prevents loading again or something similar, but I can't reproduce
 it at will sadly, so hard to say.
 
 I grabbed the attached debug.
 
 Doesn't tell me much other than the card loads OK, but the sinks/sources
 do not. I've not picked at the code yet to discover potential failure
 points, but figured I'd ask here as a first step.
 

The logs look as if the off profile is simply the one that is being
restored.

Could you reproduce this and the generated the debug output during a
profile switch that doesn't work? I.e. start up PA so that it is broken,
then begin logging, change the profile, stop logging. Then attach
logging here!

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] [alsa-devel] [RFC] disabling ALSA period interrupts

On Thu, 29.04.10 17:38, pl bossart (bossart.nos...@gmail.com) wrote:

 Howdy,
 When PulseAudio is used and all PCM is routed through PulseAudio
 (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
 PulseAudio uses a timer to refill buffers and the period interrupts
 are not used at all.

This patch looks very interesting and desirable. This is something have
long been waiting for.

I wonder how this actually relates to
snd_pcm_sw_params_set_period_event() though.

 So why not disable them entirely to reduce the number of wakeups? This
 is possible with a number of existing DMA controllers. The simple
 patch attached shows a proof-of-concept on HDAudio, it's been working
 for 5 hours on my Fedora12 laptop without any glitches and powertop
 does show _zero_ wakeups from the HDAudio controller (except on
 startup). I am told by my colleagues working in Windows environments
 that this is what's done on Vista/Windows7 btw. This isn't to say
 Windows is great but that artificial generation of not-needed
 interrupts is avoidable.
 
 There are probably some cases where you don't want this type of
 behavior (broken hardware, legacy code with multiple-buffering,
 disabled timer in PulseAudio), so I think it would make sense to
 request the disabling of interrupts when hw_params are set, since this
 is also the time when period sizes are set. I am aware that some
 changes would be needed in pcm_lib.c, where all the error checks are
 done. Takashi, Jaroslav, Lennart, what do you think?

I am sold!

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] permanent microphone boost

On Thu, 06.05.10 09:24, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 
 'Twas brillig, and Piscium at 05/05/10 19:00 did gyre and gimble:
  I am completely ignorant about audio stacks, so I don't know if mic
  boost belongs in Alsa or PA. However as far as I know the only audio
  GUI that comes in the default installation for some distros is
  PulseAudio's. So from a usability point of view it would be nice to
  have a tick box for mic boost there. Such a tick box is for example
  available in Windows.
  
  So I am happy that I found how to solve my problem with the help of
  the forum, but other people are probably not so lucky!
 
 Well the solution you're using is not really a good one. It will not
 work when a mixer probably controls that element, which AFAICT is what
 should happen.
 
 Perhaps it's just not handled properly (despite the fact that on the
 surface the code looks like it should work).
 
 I'll ask Lennart to comment to hopefully get to the bottom of the real
 problem.

If the 20dB are needed for this specific mike, and not for all mikes on
the soundcard then this looks like something we probably should cover in
the mixer logic in PA. (if it is needed for all mikes, then the alsa
init db should be fixed instead)

Please attach the excerpt of amixer -c0 about the one switch that made
things work for you and we can add it to the PA mixer database.

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] Fix crash on jack server shutdown

On Mon, 03.05.10 19:15, David Henningsson (launchpad@epost.diwic.se) wrote:

 I'll just resend my patch after having discussed it on LAC with Lennart.
 Compared to the previous patch this patch also adds a comment Lennart
 wanted, and also does the same change for jack sources.

Thanks! 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] [alsa] add rewind-safeguard parameter

On Thu, 29.04.10 11:14, pl bossart (bossart.nos...@gmail.com) wrote:

 This is a patch to fix rewind issues. It has the potential to break
 audio in Linux, so I would really appreciate it if others could give
 it a try and test on their systems. The new rewind_safeguard should be
 tuned to the DMA burst size plus some headroom; I chose a default
 value of 256 bytes but some exotic embedded hardware might require a
 different setting. On my HDAudio test system, 128 bytes was already
 more than enough to prevent audible noises.
 Thanks for your feedback.

Hmm, I had to think about this a bit, but I do agree now that this is a
good thing.

In the long run, this should probably be done by ALSA (or at least tuned
to some value reported by ALSA), but the patch makes a lot of sense to
me, and certainly more sense that the watermark value that we currently
stay away from the write index.

So, I decided that the code is good and suitable for master and have
hence commited it. I don't expect problems with it, but we can still
change it later on if there turn out to be problems.

Thanks,

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] My computer thinks I'm schizophrenic, is PA for me?

On Mon, 19.04.10 19:23, Jan Braun (janbr...@gmx.de) wrote:

1;2400;0c Lennart Poettering schrob:
   ...and you're explicitly disallowing cross-user shm transfer. :(
   I guess I'll have to figure out the security implications of messing
   with that.
  
  Well, the story goes like this: we need to make sure that a user A
  cannot trigger a SIGBUS in processes by user B simply by ftruncating an
  shm region A controls and B maps and accesses. Since handling SIGBUS
  from a library context is ugly to impossible we hence generally don't
  allow shm data transfer between users.
 
 Thanks for the explanation. But this is only a DoS, isn't it? 

Yes, it is 'just' a DoS vulnerability.

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] rtkit: add pid as argument

2010-04-25 Thread Lennart Poettering

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

Re: [pulseaudio-discuss] Does pulseaudio require alsa/oss

On Fri, 23.04.10 00:43, Nix (n...@esperi.org.uk) wrote:

 It is not mentioned in any of the (seriously limited) documentation in
 the console-kit source tree. The comment at the top of the source file,
 helpfully *below* a massive copyright boilerplate to make it easy to
 miss, reads 'Gate a process inside of a ConsoleKit session', which does
 not indicate to me that it would do a thing if you ran it on its own
 (though obviously if you gave it a process to run, I'd expect that
 process to be running inside a CK session).
 
 If you run it without parameters, it runs a shell, so running it in the
 background like that looks... unhelpful.
 
 Fedora, at least, doesn't use ck-launch-session: it uses
 ck-xinit-session, which is not in upstream console-kit at all; it's in
 the RH-specific xinit package. It's derived from ck-launch-session but
 does some incomprehensible-to-non-dbus-hackers and uncommented thrashing
 about with dbus first. It too appears to run a shell and then exit, so
 how it does what it does is equally mysterious to me. Of course, it,
 also, has no documentation whatsoever.
 
 I love the new Linux world. :/

Instead of complaining, why don't you try to help? Try to figure out
what is really going on, I am pretty sure the authors will be helpful
and give you a few hints on IRC. Then put together some documentation
patches based on that and post them. I am pretty sure they'd be well
received.

And then the next time somebody wonders what all this is about he'll be
thankful.

Free Software is not a one-way street. Contributions always welcome.

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] Does pulseaudio require alsa/oss

On Fri, 23.04.10 10:20, David Kågedal (dav...@lysator.liu.se) wrote:

  Would you prefer some completely unknown and mysterious system to one
  you actually can poke about with and figure out? Honestly, if this
  bothers you, do something about it - speak to the people involved and
  help write the docs. Moaning solve precisely nothing.
 
 I don't think that's what he meant. There are upsides and downsides to
 how Linux works and is developed. I have felt the same frustration about
 these kinds of new subsystems that lack documentation. Most recently it
 was udev that has no description about its properties, not even in the
 source code.

Well, the development of Linux is fast and the manpower limited. It is
sometimes hard to keep up with the docs about that. However, I am pretty
sure that the folks responsiblke for the code usually are happy to
respond to any questions people might have. And for udev that is
particularly true, as the hotplug ML is quite responsive, and #udev is
too.

Maybe the documentation for some projects is terse, but the people
working on them are very easily accessible, and are happy about
contributions in any way including in form of documentation.

Maybe some more traditional software systems provide better
out-of-the-box documentation, but they certainly don't have their
developers that easily and publicly accessible.

 Of course we have to moan, otherwise will never document anything they
 do. And asking people who know absolutely nothing about something quite
 complex and obscure to write the documentation soves precisely nothing.

Well, in the end the sources are all open. That means that ultimtely
everything can be documented, even without cooperation from the
developer.

That said developers are usually very open in the free software
community. They are just not that into writing documentation (me
included), or even good at it due to language barriers and the
like. Contributions always welcome.

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] Does pulseaudio require alsa/oss

On Fri, 23.04.10 10:25, David Kågedal (dav...@lysator.liu.se) wrote:

 And no, I'm not asking for big manuals presenting everything in perfect
 style. But I'm asking developers to add some notes about how stuff
 actually works. I think that Lennart is good at this, for example.

Actually, the PA docs are quite lagging. We could definitely use some
help on that... ;-)

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] Does pulseaudio require alsa/oss

On Sat, 24.04.10 15:37, Nix (n...@esperi.org.uk) wrote:

  Would you prefer some completely unknown and mysterious system to one
  you actually can poke about with and figure out? Honestly, if this
  bothers you, do something about it - speak to the people involved and
  help write the docs. Moaning solve precisely nothing.
 
 I can't write the docs for something I don't understand, and I'm too
 busy trying (and presently failing) to track down bugs in X, the kernel
 and KDE to spend time documenting this right now, particularly since it
 seems to be mostly GNOMEish, and GNOME and I get on like oil and
 water.

Well, as Colin pointed out CK is not really GNOME specific. It is used
on virtually all modern distros, and unrelated to any specific desktop
environment.

So, as you write above X and the kernel and KDE are imperfect und
incomplete too. So pointing fingers at CK is a not really fair, is it?
Manpower is limited. And most devs involved aren't lazy, so what is
there to complain about? YOu yourself admit that you are busy on
tracking down bugs, so you don't find time to track down this one in
CK. Maybe the devs of CK have more on their plate then writing docs for
CK, and priorized things so that CK docs are not first priority? Maybe
they are fixing bugs in X or the kernel too, as we speak?

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] Does pulseaudio require alsa/oss

On Sat, 24.04.10 17:40, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 
 'Twas brillig, and Nix at 24/04/10 15:37 did gyre and gimble:
  On 23 Apr 2010, Colin Guthrie told this:
  
  'Twas brillig, and Nix at 23/04/10 00:43 did gyre and gimble:
  Fedora, at least, doesn't use ck-launch-session: it uses
  ck-xinit-session, which is not in upstream console-kit at all; it's in
  the RH-specific xinit package.
 
  Can you say which pacakge provides that file? It doesn't seem to be part
  of the main ConsoleKit spec (i.e. with a patch).
  
  xorg-x11-xinit-1.0.9-14, in Fedora 12 anyway.
 
 Ahh right. Yeah we carry the same patches too and have done for ages.
 
 I'm not super familiar with how that bit of x initialisation works but I
 believe that other login managers (e.g. gdm, kdm) do similar things and
 this just allows things to work equally nicely if you run startx from a
 tty rather than going via a more common graphical login manager.

Well, non-login-manager managed X sessions are not really what most
desktop devs folks design their stuff for. gdm links directly against
CK, other dms might only support it via the pam CK connector, and startx
sessions are supported via that CK launch xinit kludge.

It is only understandable if the desktop devs work on the commonly used
code paths and only offer minimal support for legacy console-based logins.

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] More on the native protocol complexity

 not too many of those commands are necessary of basic
clients. The majority is used exclusively by software like pavucontrol.  

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] More on the native protocol complexity

On Fri, 23.04.10 09:04, Dan Kegel (d...@kegel.com) wrote:

 
 On Fri, Apr 23, 2010 at 8:10 AM, Rafal Wojtczuk
 ra...@invisiblethingslab.com wrote:
  Again, can I have a simple sound sharing over network protocol, pretty
  pretty please ? Raw audio frames + simple synchronization, anyone ?
 
 RTMP might be suited for that:
 http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol
 It used to be Adobe-proprietary, but there are several lively
 open source projects using it now.

Well, that doesn't do time synchronization AFAICS. It's not suitable in a
general purpose audio pipeline.

One of the simplest protocols for audio passing is certainly RTP, and it
is much better understood than RTMP.  RTP is a very good building block
for audio systems like the one requested here, and PA in fact has
support for it in a limited way. But it is only a building block really,
which means that a clean solution would require some hackery on top of
what exists right now.

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] More on the native protocol complexity

On Fri, 23.04.10 17:10, Rafal Wojtczuk (ra...@invisiblethingslab.com) wrote:

  That way you don't need to run pulseaudio on a top security machine.
 Yes, but the machine running pulseaudio may interact with other machines of
 high security status, thus it is important to not make its security too weak.
 
 Again, can I have a simple sound sharing over network protocol, pretty
 pretty please ? Raw audio frames + simple synchronization, anyone ?

I am not aware of any realisitcly usable existing system that would fit
your requirements. Sorry. 

At RH our approach reagrding audio in VMs is actually to simply use
virtualized sound cards. That is crappy (because they don't model the
extra latency), but works quite well otherwise, and the vulnerable
interface is limited to the pseudo hw iface presented to the virtualized
OS.

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] rtkit: add pid as argument

On Sun, 25.04.10 02:30, Maarten Lankhorst (m.b.lankho...@gmail.com) wrote:

 What concerns me a bit here is that RT programs must be written in an
 RT specific style to make sense. That means they must internally know
 which threads to make RT and which ones not, and when. From the
 outside of the codebase that is difficult to control, especially since
 information about threads in processes is not really available from the
 outside on Linux (yes, you can find out about them, but you don't really
 know which one is which...).

 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.

OK, I think I underfstand.

 If those applications would try to do bad things on windows xp you
 could lock up the entire system, since it will not reset the
 scheduler, even if that means on a single core system that it will
 lock everything else out. ;)

Well, Linux is not too much different there, unless rtkit enforces some
policy on handing out RT.
 
 Also, RT programs must be RT from beginning of their RT code to the
 end. If you control their RT scheduling only from the outside this is
 almost definitely racy. If you want to control RT privs from outside of the
 process, then the only non-racy way would be to use inheriting across an
 exec(), which however is something rtkit explcitily prohibits.
 I am also wondering how many people would use this functionality instead
 of the lower level, chrt(1) command?

 Well, I'm aware rtkit is pulseaudio only, but there have been some
 people who already use SCHED_RR with wine, mainly people who use it
 for professional audio with jack or asio. This patch is not
 officially part of wine, because of the possibility of abuse and
 forkbombs. Out of tree patches are used.

Oh, actually rtkit is not PA only. I do encourage use in other
applications, and I know some already do. rtkit is supposed to be a way
that user software can acquire RT priv safely and while being
supervised, regardless if that user software is PA or something else.

 What would prevent a process from using ptrace on another process
 with the same uid, and then request realtime priorities from it? I
 just want it somewhat easier, in a way that I can use it in wine. :)

Well, my reluctance was not really based on security concerns.

 So, convince me!

 I'm not sure how this patch would encourage writing improper rt
 code, since you could just use rtkit.c in your project for rt
 already. This will just let wine benefit from the existing
 functionality in a saner way.

OK, I am convinced. ;-)

And yes, your use of rktit certainly makes a lot of sense.

Patch looks goot to me. But could you fix one thing: I think
MakeThreadRealtimeWithPID() (or something like tht) would be a better
name than MakeThreadRealtime2(). After examples like wait(), wait3() and
wait4() in Linux, I cannot say I am a big fan of numbering function
calls. ;-)

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] Does pulseaudio require alsa/oss

2010-04-21 Thread Lennart Poettering

On Wed, 21.04.10 08:50, Colin Guthrie (gm...@colin.guthr.ie) wrote:

[ The quoting style of the original mail is completely borked, causing
my mailer to eat the biggest part of it automatically when
replying. That's why I am replying here. John please fix your mailer. ]

  ). D: cli-command.c: Checking for existance of
  '/usr/local/lib/pulse-0.9.21/modules/module-udev-detect.so': success 
  I: module-udev-detect.c: Found 0 cards. I: module.c: Loaded
  module-udev-detect (index: #4; argument: ).
 
 Something seems wrong here... I suspect your udev setup is somehow
 broken but I'm not an expert WRT udev so can't really say for sure.

Well, my educated bet is that the kernel has some deprecated sysfs
switches on.

It is highly recommended to let your distributor figure things like this
out, as they usually know which switches are needed to make things
properly these day. Use distribution kernels! Use the knowledge and
experience of your kernel maintainers!

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] Does pulseaudio require alsa/oss

2010-04-21 Thread Lennart Poettering

On Wed, 21.04.10 14:00, John Frankish (j-frank...@slb.com) wrote:

Your quoting is still broken. Please fix that.

 Well, my educated bet is that the kernel has some deprecated sysfs
 switches on.
 
 It is highly recommended to let your distributor figure things like this
 out, as they usually know which switches are needed to make things
 properly these day. Use distribution kernels! Use the knowledge and
 experience of your kernel maintainers!
 
 Lennart PoetteringRed Hat, Inc.
 
 So, a plug for red hat then :)

No. Just a plug for not reinventing the wheel over and over again and
for using the work somebody else already did for you. If you use Fedora
or Ubuntu, or Suse, or Mandriva: their kernels don't suffer by these
problems.

But what I suggested above, is really most likely your problem. You need
to disable CONFIG_SYSFS_DEPRECATED_V2 and friends in the kernel. Even
though you apparently don't take hints from RH people seriously, you
should in this case.

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] Does pulseaudio require alsa/oss

2010-04-20 Thread Lennart Poettering

On Tue, 20.04.10 16:04, John Frankish (j-frank...@slb.com) wrote:

 Hi,
 
 Dumb question maybe, but..
 
 Does pulseaudio require alsa or oss to be configured to detect a soundcard or 
 should it detect the soundcard without either alsa or oss configured?
 
 The reason I ask is that the pulseaudio udev module will not detect
 the soundcard on my dell latitude D430 with/without alsa configured,
 but module-detect will detect the soundcard as long as alsa is
 configured.

Uh? ALSA is the Linux sound driver interface. Without it your audio
hardware will of course not be accessible.

(And forget about OSS)

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] New kernel 2.6.34-rc4, no audio

On Sun, 18.04.10 21:09, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 
 'Twas brillig, and Daniel Chen at 18/04/10 20:50 did gyre and gimble:
  On Sun, Apr 18, 2010 at 2:44 PM, Gene Heskett gene.hesk...@verizon.net 
  wrote:
  Pulseaudio-vvv is the file you want to click on.  I am seeing a file list 
  at
  http://gene.homelinux.net:85/gene/Genes-os9-stf/
  
  From your posted log file:
  
  D: module-udev-detect.c: /dev/snd/controlC0 is accessible: no
  [...]
  D: module-always-sink.c: Autoloading null-sink as no other sinks detected.
 
 
 Yup, so for whatever reason we can't access this file. Possibly because
 it doesn't exist. i.e. your problem is with the alsa setup.

Looks more like a perms problem to me. Check if the ACLs are properly
set up and follow the user that is logged in and active on the seat.

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] New kernel 2.6.34-rc4, no audio

On Sun, 18.04.10 16:34, Gene Heskett (gene.hesk...@verizon.net) wrote:

 
 On Sunday 18 April 2010, Colin Guthrie wrote:
 'Twas brillig, and Daniel Chen at 18/04/10 20:50 did gyre and gimble:
  On Sun, Apr 18, 2010 at 2:44 PM, Gene Heskett gene.hesk...@verizon.net 
 wrote:
  Pulseaudio-vvv is the file you want to click on.  I am seeing a file
  list at http://gene.homelinux.net:85/gene/Genes-os9-stf/
 
  From your posted log file:
 
  D: module-udev-detect.c: /dev/snd/controlC0 is accessible: no
  [...]
  D: module-always-sink.c: Autoloading null-sink as no other sinks
  detected.
 
 Yup, so for whatever reason we can't access this file. Possibly because
 it doesn't exist. i.e. your problem is with the alsa setup.
 
 Col
 
 IIRC that particular config didn't pre-allocate the oss stuff, and wasn't 
 building any oss compat stuffs either.  Is that related?  I don't know if the 
 one that works does, from the working .config:

This has nothing to do with OSS.

I generally recommend using distribution kernels, since they are usually
compiled in a way that most things like this work.

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] Pulse audio does not work with my hdmi output

On Sat, 17.04.10 01:03, Dark Shadow (shadowofdarkn...@gmail.com) wrote:

 With todays Alsa 1.0.23 release I finally have working HDMI audio on
 my laptop with the exception of through Pulse Audio.
 
 mplayer video.mkv -ao alsa:device=plughw=1.3 works perfect, but when
 I set Pulse Audio to output to my hdmi device I get silence with the
 occasional popping sound.

Well, plughw:1,3 is a hack, and specific to your hardware. Normally
the hdmi:1 device should work right-away. If it doesn't, then this is
an ALSA problem.

Note that HDMI on Linux is still very shaky ground and little tested.

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] Pulse audio does not work with my hdmi output

On Sat, 17.04.10 03:51, Dark Shadow (shadowofdarkn...@gmail.com) wrote:

 
 Ok I found out more, it can work but I have to do a step first. My
 testing before was pulseaudio then alsa but I never went back to
 notice that pulse started working.
 
 It seems on my hdmi output that after ever boot I have to use 1,9
 first then it initializes 1,3 1,7 1,8 and they work fine after that.
 
  So all I need to know is how can I force Pulse Audio to use
 plughw:1,9 always instead of the first detected 1,3?

Specifying device indexes in addition to card indexes is highly card
dependant. If other device indexes need to be used, then the hdmi:xxx
string needs to be fixed in ALSA. PA will then automatically pick up
things the right away.

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] My computer thinks I'm schizophrenic, is PA for me?

On Fri, 16.04.10 21:02, Jan Braun (janbr...@gmx.de) wrote:

 Hi list,
 and sorry for bringing up this topic again, but I'm another user who
 has difficulties with PA's multi-user policy.
 
 You see, currently I'm the only person with access to my desktop pc,
 but I have several user accounts on it[1]. And I use them all.
 Simultaneously. As in: several consoles open, often more than 1 xserver
 running, 

You know, they invented window managers that support multiple
workspaces. Fantastic stuff. You should try it once.

 xterms ssh'd to otheru...@localhost .

Why would you ssh to the local machine?

Anyway, having one user with a split personality and hence is actually
five users is certainly nothing I designed PA for. 

Sorry,

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] My computer thinks I'm schizophrenic, is PA for me?

On Sat, 17.04.10 16:42, Jan Braun (janbr...@gmx.de) wrote:

  My suggestion is basically the same as your option 3, without the double
  mixing and tcp overhead (I'm not sure whether using the loopback
  interface has much more overhead than unix domain sockets, though - you
  still won't be able to use shared memory for audio transport).
 
 Hmm, why not? I've set up PA as you describe (except for the additional
 auth-group parameter), and PA is creating entries in /dev/shm , even for
 other users than albert.

The PA client libs always allocate their memory from an shm region,
regardless whether it is later used for data transfer or 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] My computer thinks I'm schizophrenic, is PA for me?

On Sat, 17.04.10 18:28, Tanu Kaskinen (ta...@iki.fi) wrote:

 
 On Sat, 2010-04-17 at 16:42 +0200, Jan Braun wrote:
  Hmm, why not? I've set up PA as you describe (except for the additional
  auth-group parameter), and PA is creating entries in /dev/shm , even for
  other users than albert.
 
 Oh, maybe shm does work? I assumed that the logic was that only
 connections from the same user could use shm, but maybe the logic is
 that shm is forcibly disabled only in the system wide mode.

We do compare the local and remote uid and refuse SHM if they don't
match. On top of that we always disable SHM for root.

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] Getting cork notifications/subscritpions for other streams

On Thu, 15.04.10 09:05, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 Hi Lennart,
 
 I've looked at the API, but maybe I was too drunk...
 
 Is there any way that I can get a subscription callback or similar when
 a stream is corked? Due to the nature of this integration, the playback
 stream itself is actually hidden from me... so I cannot check
 pa_stream_is_corked() or anything like that.

We currently expose no information about that, but we probably could add
that to the sink_input_info data.
 
 Ideally it would just be another subscription that I could subscribe to.
 
 Is this possible? If not, is there a reason it's not, and if there is no
 reason, would you mind if I implemented it :)

What would you use this for?

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] [alsa-devel] pulseaudio eats 19% CPU power in Fedora 12

On Wed, 14.04.10 15:56, Wu Fengguang (fengguang...@intel.com) wrote:

 Hi Lennart,
 
 We found that pulseaudio eats CPU ~19% CPU time, a little more than
 mplayer when playing video. This is horrible for laptop batteries.

This is not a particularly useful report. 

You know, this can have so many different reasons, the only thing I can
really say, is that you can rest assured that it is not supposed to eat
that much in normal use.

The CPU usage of PA is primarily dependant of the latency requested by
the clients. Low latency means high CPU load. Lower latency means higher
CPU load. Try pacmd list-sink-inputs to figure out the latency the
various applications requested.

Then there can be driver problems, where the timing information is not
entirely correct that ALSA passes on to, with the result that we get
dropouts where we shouldn't, with the results that we shorten our sleep
times, with the final effect that the CPU usage goes up.

Of course, if PA is used resampling and suchlike is moved from the
clients into the sound server and hence will be added to its CPU
usage. And PA uses a better resampler by default than ALSA traditionally
did, hence the CPU use will be a bit higher than plain ALSA.

And then of course, the CPU usage depends on the CPU used. Is this some
embedded hardware?

In summary: if you want to know what is going on, you need a suitable
tool, like a profiler and do the dirty work to figure out what is going
on. Just saying 19% is not helpful to figure out what is going on.

On my machine here it uses 3% CPU while playing.

 Can we make it just work -- in green CPU mode? 

Yes, sure. If you use pacat you can play audio with almost zero CPU
usage, because it is one of the few clients that actually asks for
sensible latency (2s), which allows us to minimize the wakeup intervals
to less than a second.

 I can find many users
 complaining about this, and it seems like some fix is available in
 this link:
 https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135

Fix? Where?

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] Standardising on the amount of software amplification is presented to the user

On Wed, 14.04.10 11:38, Colin Guthrie (gm...@colin.guthr.ie) wrote:

  In VLC the 400% relates to a +6dB overdrive so a +3dB for them is 200%
  (and one of their devs said to me that he didn't think that anything
  over +3dB should be shown to the user). Perhaps even this is too far?
  
  In PA +6dB is at 125% or so (with the current mapping algorithm).
 
 Ahh good. I figured it wouldn't be 400% in PA, but hadn't done the
 actual sums :)

Hmm, one more addition to this. I find myself pulling up the volume
slider to the full 150% exposed in g-v-c from time to time when using
unamplified headphones on a USB sound card on a movie, and I am kinda
happy that I can do that. That's +10dB (amplitude) or so. So limiting
things to +6dB looks a bit too low for me.

  We currently use the same cubic mapping both below and above 100%. I am
  not sure that is even a good choice, and if we shouldn't change that one
  of those days.
 
 From what I've discussed with the VLC guys this morning (and I wont
 pretend to fully grok all the mappings involved) they seem to suggest a
 +3dB = 200% and a +6dB = 400%. This seems to me like they've used a
 linear mapping and that they use 10log(x) rather than 20log(x) which is
 normally used for sound pressure (as far as I understand it - which is
 admittedly limited).

Hmm, their dB scale is based on power, not amplitude. As it
seems. Interesting choice, but I am kinda sure that most vol controls
focus on amplitude, not power. And PA does too. And ALSA as well.

Choosing a linear mapping is a pretty bad choice, so much as definite.

http://www.robotplanet.dk/audio/audio_gui_design/
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-May/thread.html#23151

  #define PA_VOLUME_OVERDRIVE (PA_VOLUME_NORM+PA_VOLUME_NORM/2)
 
 OK, so if I've done my sums right (150% = 1.5 relative to PA_VOLUME_NORM
 = linear[1.5^3] = linear[3.375] = dB[20*log(3.375)] = db[20*0.528] =
 db[10.57]) we could actually do:

 #define PA_VOLUME_OVERDRIVE (pa_sw_volume_from_dB(+10.57f))
 
 This will map to the current 150% used by g-v-c. e.g. this is the amount
 by which it currently allows overdrive.

Yepp, that is true. Though this is actually a double, not a float, the
'f' should go.

 So the real question is, what should the overdrive dB value be? The 3dB
 or 6dB currently supported in vlc's UI or something we define ourselves.
 I agree that making it a dB value is sensible tho' ;)

I am quite happy with the current mapping in g-v-c to be honest, and so
far I haven't heard any complaints that it was too little.

So to make things clean we could just say +11dB (amplitude) as max. And
claim this is the ultimate truth. ;-)

 #ifndef PA_VOLUME_OVERDRIVE
 # define PA_VOLUME_OVERDRIVE (pa_sw_volume_from_dB(+10.57f))
 #endif
 
 So that I can use the new constant in the code to replace any hardcoded
 (1.5*PA_VOLUME_NORM)s or just PA_VOLUME_NORMs on their own depending on app.
 
 Does that seem sensible?

Yes, absolutely.

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] New kernel 2.6.34-rc4, no audio

On Sun, 18.04.10 23:48, Gene Heskett (gene.hesk...@verizon.net) wrote:

 g...@coyote /]$ ls -l /dev/snd
 total 0
 drwxr-xr-x  2 root root   60 2010-04-18 07:47 by-path/
 crw-rw+ 1 root audio 116,  0 2010-04-18 07:47 controlC0
 crw-rw+ 1 root audio 116,  4 2010-04-18 07:47 hwC0D0
 crw-rw+ 1 root audio 116,  8 2010-04-18 07:47 midiC0D0
 crw-rw+ 1 root audio 116,  9 2010-04-18 07:47 midiC0D1
 crw-rw+ 1 root audio 116, 24 2010-04-18 23:44 pcmC0D0c
 crw-rw+ 1 root audio 116, 16 2010-04-18 23:44 pcmC0D0p
 crw-rw+ 1 root audio 116, 25 2010-04-18 07:47 pcmC0D1c
 crw-rw+ 1 root audio 116, 26 2010-04-18 07:47 pcmC0D2c
 crw-rw+ 1 root audio 116, 18 2010-04-18 07:47 pcmC0D2p
 crw-rw+ 1 root audio 116, 19 2010-04-18 07:47 pcmC0D3p
 crw-rw+ 1 root audio 116,  1 2010-04-18 07:47 seq
 crw-rw+ 1 root audio 116, 33 2010-04-18 07:47 timer
 [g...@coyote /]$
 
 And that is after killing the daemon with killall as root, and restarting it 
 as me, gene with a pulseaudio -vvv  and getting several screens of output. 
  
 
 Is that the right perms?

You need to check the ACLs: see getfacl(1).

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] Standardising on the amount of software amplification is presented to the user

2010-04-13 Thread Lennart Poettering

On Tue, 13.04.10 15:10, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 Hi,
 
 I'm trying to solve a bug where by mplayer is clamping the volume at
 100%. If someone turns up the volume to 100% using e.g.
 gnome-volume-control, hitting volume up or down in mplayer will reset it
 to 100% again.
 
 For a quick straw poll:
 
  g-v-c: 150%

Unfortunately g-v-c-a limits to 100%. Which is kinda weird.

  pavucontrol: 100%
  kmix  phonon: 100% (I wrote this so only me to blame!)
 
  vlc: 400% (but does not yet use PA per-application volume control).
  mplayer: 100%
 
 + numerous others.

Well, and for all of those the meaning of 150% probably differs. And it
probably makes more sense to speak about dB here.

 Now I believe we need some kind of standard amount of overdrive.
 Obviously we want to push the applications into using per-stream
 volumes, but this only really works if they all use the same range.
 
 What is the best way to do this? Should we just decide on it now and
 then push this out to the apps? Should we have a constant? e.g.
 PA_VOLUME_OVERDRIVE == +3dB or something?

Hmm, this is purely a UI decision, not sure this belongs in PA. And
also, this all depends on whether the device does decibel volume scaling
at all. If it doesn't you need to end things at 100%.

 In VLC the 400% relates to a +6dB overdrive so a +3dB for them is 200%
 (and one of their devs said to me that he didn't think that anything
 over +3dB should be shown to the user). Perhaps even this is too far?

In PA +6dB is at 125% or so (with the current mapping algorithm).

We currently use the same cubic mapping both below and above 100%. I am
not sure that is even a good choice, and if we shouldn't change that one
of those days.

We probably should say that applications should end their scale at +6dB
and in the PA case they should map that back via pa_sw_volume_from_dB() to a
percentage, so that we have the freedom to change the mapping later on,
without changing the meaning of the overdrive setting.

So, we could do this:

#define PA_VOLUME_OVERDRIVE (pa_sw_volume_from_dB(+3.0f))

instead of this:

#define PA_VOLUME_OVERDRIVE (PA_VOLUME_NORM+PA_VOLUME_NORM/2)

And then have the freedom of changing our mapping. OTOH that would mean
that volume scales would end at a weird 112%. 

But yes, I guess I am not opposed in adding something like this.

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] Sound output is muted at 16% volume

2010-04-13 Thread Lennart Poettering

BOn Mon, 12.04.10 11:58, Marti Raudsepp (ma...@juffo.org) wrote:
1;2400;0c
 
 Hi Colin, thanks for your response. Any comments about the other problem 
 though?
 
  'Twas brillig, and Marti Raudsepp at 11/04/10 21:06 did gyre and gimble:
  I tried working around this by changing the PCM level in alsamixer,
  but whenever a new client connects, PulseAudio thinks it's smarter
  than me and resets the PCM mixer -- to somewhere between 0.00 ...
  -0.60 dB (?!), and sets the master level to 0% again
 
  So there are 2 distinct problems:
  [...]
  2. If PulseAudio wants to maximize some volume controls, it should set
  them at 0.0 dB, not -0.60 dB

The logic in PA is to set the hw volume to the smallest volume step that
is higher or equal to what PA needs and then the rest we attenuate in
software.

It would be interesting to see what volume actually posesses for the
relevant mixer controls. For that it would be interesting to have a look
on the amixer output when you have set it to 0dB, and when PA has set it
to what it things is 0dB.

Also note that PA actually controls the entire mixer pipeline, so quite
possibly some limitation of a preceeding mixer element causes this minor
attenuation on the mixer element you are looking at.

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] Documentation on the wire protocol for native-protocol-tcp?

2010-04-05 Thread Lennart Poettering

On Mon, 05.04.10 09:52, david.hag...@gmail.com (david.hag...@gmail.com) wrote:

 I'm trying to find documentation on the wire protocol that the
 native-protocol-tcp uses, but haven't found it yet. Yes, I could Use The
 Source, but reverse-engineering the wire protocol from that vs. reading an
 already written definition of a protocol is not an efficient use of my
 time.

It's only in the sources, sorry.

 If there is such documentation I'd appreciate a link, if not, then I'd
 like to know if the wire protocol is sufficiently fixed to make working
 out the wire protocol make sense.

Unless we broke anything accidently we should still be compatible with
0.9.0, which is quite old.

 
 My need is that I have a signal processing hardware module that:
 1) Makes audio
 2) Accepts audio
 3) Can speak TCP
 4) I'd like to tie into a Pulseaudio server.
 5) would be inconvenient to load all of Pulseaudio on.
 
 So if I could get the wire protocol it would not be hard to generate that.

Note that the protocol is kinda complex, both because it grew
historically and because some parts have to be complex. i.e. the
timing/flow control logic is non-trivial. Reimplementing that won't be
fun.

tbh I don't think the native protocol while it works quite well these
days is something that deserves to be reimplemented by other projects.

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] Documentation on the wire protocol for native-protocol-tcp?

2010-04-05 Thread Lennart Poettering

On Mon, 05.04.10 11:33, david.hag...@gmail.com (david.hag...@gmail.com) wrote:

  tbh I don't think the native protocol while it works quite well these
  days is something that deserves to be reimplemented by other projects.
 
  Lennart
 
 Do you have any good suggestions on what course of action I should follow?
 Would it make more sense to look at the simpler streams and do my own
 network protocol (in this case, the processing module is connected to the
 main processor over a backplane network link, so the transport is highly
 reliable.).

Depends on what you want to do. I think the future is some kind of RTP,
and PA speaks that, but not really for normal clients, although I
eventually plan to change that.

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] PulseAudio sample type conversion and quality

2010-03-31 Thread Lennart Poettering

On Wed, 31.03.10 12:10, Oscar Eriksson (oscar.r.eriks...@gmail.com) wrote:

 Hi,
 
 I'm curious about how the conversion from 32-bit float PCM to 16-bit fixed
 PCM is done in PulseAudio. Or is it Alsa that takes care of this
 conversion?

PA does.

 Are noise shaping and dithering involved?

No and no. I thought about adding at least dithering, but uh, I don't
think this is really a priority for desktop audio. Dithering is primarily
relevant for audio production which PA is unsuitable for anyway, and
the operation is too CPU intensive to do it nonetheless.

(ALSA doesn't do thopse things either in their converters)

 Also, how do I adjust the volume for optimum playback quality when playing
 music? (I want to use the the full dynamic range) Should I use maximum ALSA
 and PulseAudio volume when playing songs that have been normalized (Replay
 Gain)?

For the sliders PA exposes 0dB is at maximum hardware volume, and the
base volume is where the hardware 0dB is, for whatever that means.

Hence normally you want to keep the volume below the base volume, at
least when the dB labelling of the hardware sliders are correct.

http://pulseaudio.org/wiki/WritingVolumeControlUIs#BaseVolumes

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] default device with jack sink

2010-03-23 Thread Lennart Poettering

On Tue, 23.03.10 23:33, Patrick Shirkey (pshir...@boosthardware.com) wrote:

 ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect:
 Connection refused
 
 ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect:
 Connection refused

This suggests that you are not running PA at all.

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] Fix crash on jack server shutdown

2010-03-23 Thread Lennart Poettering

On Tue, 23.03.10 00:36, David Henningsson (launchpad@epost.diwic.se) wrote:

  What is missing is that the jack loop does not depend on the PA sink to
  be around resp. the PA IO loop doesn't call into jack when it is
  dead. If either of that is implemented (and then destruction order
  matches this) the problem is fixed.
  
  Also, what applies to m-jack-sink needs fixing in m-jack-source, too.
 
 Good points. I admit to not having checked properly whether
 pa_sink_unlink and pa_sink_render_full can be called in parallell, I see
 now that they shouldn't.

Calling _unlink() and _render_full() at the same time is actually
fine. _unlink() will send a msg to the IO thread to shut down the sink
and will synchronously wait for it. _render_full() is called from the IO
thread. Since the msg dispatching and the _render_full() are run from
the same thread and hence are serialized there is no problem here.

 Since appropriate stream moving is good, and stream moving (apparently)
 needs to do a get-latency call to do its job properly, I would say that
 this was a step in the right direction.

Yes, you definitely found the problem. Only the fix is a bit harder than
anticipated.

 So, let us also send a message to the thread to stop rendering (i e stop
 calling pa_sink_xxx), before the pa_sink_unlink call? If this sounds
 like a good idea to you, I'll prepare a git patch.

Yes, that sounds like a workable solution:

1) first send a synchronous msg from the main thread to the PA IO thread
   to tell it that PA_SINK_MESSAGE_GET_LATENCY shall no longer call into
   libjack. This can be implemented by a simple bool flag that is set on the
   PA IO thread side and which is checked on each _GET_LATENCY that is
   received. Because this msg is synchronous we can guarantee that
   after the msg was fully dispatched the PA IO thread won't hang inside
   a libjack call anymore.

2) We destroy the jack object.

3) We unlink and destroy the PA sink.

AFAICS a logic like that would fix all issues.

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] Problem when loading module-always-sink or module-alsa-sink

2010-03-23 Thread Lennart Poettering

On Sat, 13.03.10 14:59, Maginot Junior (maginot.jun...@gmail.com) wrote:

 Hi,
 
 I'm developing a LFS system and since I installed Pulseaudio-0.9.21

Consider upgrading to a proper distribution where all these problems
have already been dealt with. There is no point in tracking the same
problems over and over again if somebody else already did just that for
you.

 I: main.c: Machine ID is avant.

Your D-Bus setup is very very broken. Consider upgrading to a proper
distribution with a working D-Bus installation.

 I: main.c: Using runtime directory /home/maginot/.pulse/avant-runtime.
 I: main.c: Using state directory /home/maginot/.pulse.
 I: main.c: Using modules directory /usr/lib/pulse-0.9.21/modules.
 I: main.c: Running in system mode: no
 W: pid.c: Stale PID file, overwriting.
 I: main.c: Fresh high-resolution timers available! Bon appetit!
 I: cpu-x86.c: CPU flags: MMX SSE SSE2 SSE3 SSSE3 SSE4_1

Interesting, so you have SSE4.1 and are building for 32bit? Consider
upgrading to a proper distribution that chose the right CPU architecture
when compiling.

 I: svolume_mmx.c: Initialising MMX optimized functions.
 I: remap_mmx.c: Initialising MMX optimized remappers.
 I: svolume_sse.c: Initialising SSE2 optimized functions.
 I: remap_sse.c: Initialising SSE2 optimized remappers.
 I: sconv_sse.c: Initialising SSE2 optimized conversions.
 D: memblock.c: Using shared memory pool with 1024 slots of size 64.0
 KiB each, total size is 64.0 MiB, maximum usable slot size is 65496
 D: database-gdbm.c: Opened GDBM database

Nowadays it is recommended to use tdb here, no longer gdbm. Consider
upgrading to a proper distribution where the mainatiner already made
sure that PA is linked against tdb.

 '/home/maginot/.pulse/avant-device-volumes.i686-pc-linux-gnu.gdbm'
 I: module-device-restore.c: Sucessfully opened database file
 '/home/maginot/.pulse/avant-device-volumes'.
 I: module.c: Loaded module-device-restore (index: #0; argument: ).
 D: database-gdbm.c: Opened GDBM database
 '/home/maginot/.pulse/avant-stream-volumes.i686-pc-linux-gnu.gdbm'
 I: module-stream-restore.c: Sucessfully opened database file
 '/home/maginot/.pulse/avant-stream-volumes'.
 I: module.c: Loaded module-stream-restore (index: #1; argument: ).
 D: database-gdbm.c: Opened GDBM database
 '/home/maginot/.pulse/avant-card-database.i686-pc-linux-gnu.gdbm'
 I: module-card-restore.c: Sucessfully opened database file
 '/home/maginot/.pulse/avant-card-database'.
 I: module.c: Loaded module-card-restore (index: #2; argument: ).
 I: module.c: Loaded module-augment-properties (index: #3; argument: ).
 N: alsa-util.c: Disabling timer-based scheduling because running inside a VM.
 E: fdsem.c: Assertion 'pa_atomic_dec(f-data-waiting) = 1' failed
 at pulsecore/fdsem.c:283, function pa_fdsem_before_poll(). Aborting.

This smells like a broken libatomic_ops, pulled in by a too old
compiler.

Consider upgrading to a proper distribution where the maintainers
already made sure that gcc natively supports atomic operations.

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] Fix crash on jack server shutdown

2010-03-22 Thread Lennart Poettering

On Sun, 14.03.10 20:50, David Henningsson (launchpad@epost.diwic.se) wrote:

 On sink unlinking, existing sink inputs are moved, which in turn calls
 a get latency callback, which references the jack client. Therefore,
 make sure the sink is unlinked before the client is closed. Failure to
 do so might lead to SIGSEGV.
 
 This patch simply moves the call to pa_sink_unlink above
 jack_client_close, which fixes the problem.

Uh. I don't think this really fixes the problem. This just moves things
around and replaces one race by another. 

The old race: the PA IO loop might end up calling into libjack with an
invalid jack client context after the context got destructed but the PA
sink didn't get shutdown yet.

The new race: the jack IO loop might end up calling (and blocking) into
PA code when the PA sink is unlinked (though not yet destructed) but the
jack code is not yet.

What is missing is that the jack loop does not depend on the PA sink to
be around resp. the PA IO loop doesn't call into jack when it is
dead. If either of that is implemented (and then destruction order
matches this) the problem is fixed.

Also, what applies to m-jack-sink needs fixing in m-jack-source, too.

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] PulseAudio 'git describe'

2010-03-19 Thread Lennart Poettering

On Fri, 19.03.10 18:19, Daniel Mack (dan...@caiaq.de) wrote:

 Hi,
 
 on a freshly clones pulseaudio.git, I see this:
 
 $ git log --pretty=one | head -1
 5248a584a36d49b745c1891954e9aa5e689e89a2 build-sys: Mention dbus support in 
 the summary
 $ git describe
 v0.9.19-492-g5248a58
 
 But:
 
 $ grep LIBPULSE_VERSION_INFO configure.ac 
 AC_SUBST(LIBPULSE_VERSION_INFO, [12:2:12])
 
 The commit for that v0.9.21 (06327b1e67a) is not part of the master
 branch. Am I missing anything?

That is correct. 0.9.21 was a bugfix release I based on stable-queue at
a time where master already massively diverged from it.

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] Volume too loud in headphones with Intel HDA

On Wed, 03.03.10 16:47, Ludovic Courtès (l...@gnu.org) wrote:

 Hi,
 
 The document at http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes
 didn’t really answer my question, so here we go.
 
 I’m using PA on a Dell Latitude D430 laptop that has an Intel HDA sound
 card [0] with a “headphone” jack.  When actually plugging in headphones
 in that jack, the volume is too loud, and pavucontrol doesn’t allow me
 to make it softer: if the master or per-application volume slider is
 moved below a certain threshold (around 20), it becomes completely
 silent.

Sounds like a case of incorrect dB information.

http://0pointer.de/blog/projects/decibel-data.html
http://pulseaudio.org/wiki/BadDecibel


 [0] FWIW, here’s the beginning of the output of ‘dbverify’:

So, you did find our about dbverify. The printed output of it is quite
irrelevant, what matters is what your listening tests with it
reveal. And, what do they reveal?

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] Volume too loud in headphones with Intel HDA

On Wed, 03.03.10 18:18, Ludovic Courtès (l...@gnu.org) wrote:

  Sounds like a case of incorrect dB information.
 
  http://0pointer.de/blog/projects/decibel-data.html
  http://pulseaudio.org/wiki/BadDecibel
 
 
  [0] FWIW, here’s the beginning of the output of ‘dbverify’:
 
  So, you did find our about dbverify. The printed output of it is quite
  irrelevant, what matters is what your listening tests with it
  reveal. And, what do they reveal?
 
 It all seems correct, i.e., the volume is the same for every pair of 1s
 sounds.

And which steps did you try? The output you pasted only shwos that you
tested step 30 against 31. Would be interesting to test 0 to 10, 0r 5 to
30 or so. Please play around a little!

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] Volume too loud in headphones with Intel HDA

On Wed, 03.03.10 23:17, Ludovic Courtès (l...@gnu.org) wrote:

 Lennart Poettering lenn...@poettering.net writes:
 
  And which steps did you try? The output you pasted only shwos that you
  tested step 30 against 31. Would be interesting to test 0 to 10, 0r 5 to
  30 or so. Please play around a little!
 
 Step 0 is completely silent.
 
 For 1 to 10, 1 to 15, 5 to 30, 20 to 30 there’s no audible difference in
 volume.
 
 Does this help?

And, what if you test 0 against 30? Are both tones completely silent? If
you can hear one, but not the other than there is some invalid dB data
in the driver.

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] Volume too loud in headphones with Intel HDA

On Thu, 04.03.10 01:00, Ludovic Courtès (l...@gnu.org) wrote:

  And, what if you test 0 against 30? Are both tones completely silent?
 
 No.  The first one is completely silent but the second one is audible.

Ah, there you go. The dB data for step 0 is incorrect: it claims to be
something substantially  -inf dB but actually seems to cut off audio
completely and hence should be something like == -inf dB.

  If you can hear one, but not the other than there is some invalid dB
  data in the driver.
 
 In that case, how can I work around it in the short term and help fix
 the driver in the longer term?

Dude, I wrote that wiki page for a reason: so that people read it.

So read it again:

http://pulseaudio.org/wiki/BadDecibel

File a bug against the driver/kernel in your distro bug tracker. And
explain that the dB data for your volume step 0 is invalid and that it
needs to be fixed to be more like -inf dB. I am pretty sure your distro
folks will then help you to make sure this gets fixed in the
kernel. Include the output of alsa-info.sh --no-upload there.

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] Failure to create alsa source

2010-02-28 Thread Lennart Poettering

On Sat, 27.02.10 02:43, Jenn and Alan Atherton (theathert...@gmail.com) wrote:

 Hello,
 
 I am having trouble getting the microphone on my webcam to work with pulse.
 What's odd is that it works just fine with ALSA, and pulse sees the device
 (and gives it a mono input profile), but at some point the input source
 isn't available.  I am using Ubuntu 9.10, but with pulseaudio 0.9.21 and
 ALSA 1.0.22 from an unstable repository.  I believe it's something in the
 pulseaudio side of things, since the device works fine with ALSA directly
 (e.g., through audacity).  I want to get it working with pulse, though, for
 Skype, which fairly recently moved to pulse exclusively.  I'm hoping this
 isn't a bug and merely a configuration issue, but I am not savvy with alsa
 or pulse, so I don't know what/where to tweak.  The critical lines in the
 pulse output are the last few that I've included in the long (post-message)
 excerpt from pulseaudio -vvv
 
 W: alsa-util.c: Unable to set sw params: No such device
 E: alsa-source.c: Failed to set software parameters: No such device

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=f1713475087027925358c3f9dd3db70723ed8d11

https://bugzilla.redhat.com/show_bug.cgi?id=566289

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] KDE 4.3.95 + Skype 2.1.0.81 + PulseAudio 0.9.21: big delay

2010-02-25 Thread Lennart Poettering

On Thu, 25.02.10 18:45, Werner LEMBERG (w...@gnu.org) wrote:

 On openSuSE, I use these packages, mostly from the factory repository:

Please ask your distribution to include the patches from the
stable-queue git branch in PA git. Most other distributions now
regularly apply those patches. And so should yours.

The Skype issue is fixed there.

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

2010-02-21 Thread Lennart Poettering

On Thu, 18.02.10 21:52, João Paulo Rechi Vita (jprv...@gmail.com) wrote:

 On Wed, Feb 17, 2010 at 01:21, Lennart Poettering
 lenn...@poettering.net wrote:
 
  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?
 
 
 Hi Lennart,
 
 The code is now completely merged into bluez, so it's time to upstream
 our side. Patches rebased against master attached.

Thanks! Merged!

Keep up the great work!

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] On-the-fly changing of sinks or sources in combine- and loopback-modules? Sound-distortions at the beginning of module-loopback?

2010-02-21 Thread Lennart Poettering

On Thu, 18.02.10 11:31, Peter Kornatowski (pk...@gmx.net) wrote:

 
 At 01:23 18.02.2010, you wrote:
 On Thu, 18.02.10 00:09, Peter Kornatowski (pk...@gmx.net) wrote:
 
  Hello,
 
  1. Is it possible to change the sinks or sources in an already
  loaded module-combine or module-loopback without unloading and
  reloading the module?
 
 Unless otherwise configured module-combine will automatically add all
 new hardware sinks to its outputs and drop those which go away. So
 this automatism does allow sinks/sources to be added
 dynamically/removed dynamically during runtime. However, there is no
 user API for that to trigger that in any way but by
 unplugging/plugging hardware.
 
 I am using the combiner for up to 3 bluetooth-headsets. But I have
 more headsets, so I made a program that waits for bluetooth-signals
 of a headset and then loads the headset through the asynchronous
 PA-api as module-bluetooth-device. Then I am reloading the
 module-combine with a new sink-list. Do you think I can make that
 happen automatically without reloading the module-combine?

No. As mentioned m-c can auto combine all hardware devices for
you (which includes all BT devices). So you can choose to use either
that or go entirely manual, where no run-time reconfiguration API
exists for.

 The streams module-loopback uses you can move around with pavucontrol
 or a similar tool.
 
 Can I move it with the asynchronous PA-api? And if yes, how?

pa_context_move_sink_input_by_name()
pa_context_move_sink_input_by_index()

  2. I also have a problem with sound distortions (mostly much higher
  and quicker voice) several seconds after loading the
  loopback-module (source is a bluetooth-headset and sink is my
  soundcard). After some seconds the distortions disappear and
  everything is fine. I found out that reducing the adjust_time
  parameter of the loopback-module (I had to add adjust_time to
  valid_modargs in the source code) also reduces the duration of the
  distortions, but even at adjust_time=1 they remain for about 2
  seconds (and pulseaudio uses much more CPU). Setting it to 0 doesn't
  work at all.
 
 Sounds as if there is something wrong with the device speed. which
 causes PA to compensate by resampling things.
 
 So would it be possible to fix this? Do you need more info/some logs?

Uh. this is tricky to fix. Not sure I can tell you anything that could
fix this quickly for you. Somebody has to sit down with the hardware
and really figure out what is going on, this is not really feasible
remotely.

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 Wed, 17.02.10 09:26, Colin Guthrie (gm...@colin.guthr.ie) wrote:

  4) The UI would allow the user to fix any setting the system chose
 and the system will then remember as good as possible.
 
 So intended roles should slot in here? After we've tried to find the
 right device for the stream via specific history list?

I don't think the user should see any of the automatic stuff. He
should see his own configuration, that's all. And as mentioned only
the most recent configuration, not all of it.

 My immediate thought on this is that m-i-r should be quite forceful
 here, but I'm willing to concede the point as I'm not totally convinced
 with myself. The reason I say that is that m-i-r is pretty neat with
 VoIP stuff and I'd really like it to work, but if e.g. someone uses
 VoIP-App+Webcam there is a good chance that they will have manually
 moved the VoIP-App input stream to the Webcam Mic. This means that when
 they then open a BT headset, only the output stream is moved across, and
 the input stream is still stuck on the input. That's maybe fair
 enough.

You can always come up with use cases where one of the possible
solutions chooses the wrong device. But don't forget two things: after
the user corrected this once, and with the history stuff it will stay
corrected for the future. And this case is kinda nichey.

 The alternative of course is that m-i-r does not actually do any
 internal stream moves itself, it just becomes a way to automatically
 inject devices into the role-based priority list (aka history) at the
 appropriate place. I've not looked at the code recently but IIRC m-i-r
 relies on having a specific device that is most appropriate for a given
 role. If so, then this approach could work nicely and make the order of
 rule application logic a bit simpler perhaps (due to it all being in
 m-s-r)? I'd suggest the m-i-r logic should be I've found an appropriate
 device for role X. Is device in prio-list for role X? Yes: Noop, No, Add
 it in at the top.

I am not convinced this is a good idea. User configuration should stay
user configuration and should take precedence over every kind of
automatism. Also, patching user configuration automatically sounds like
a bad idea to me.

I also like to keep things independant of each other.

 The major downside is that m-i-r would then not work without m-s-r and
 I'm not sure that's a great idea for embedded/phone people who may or
 may not actually want m-s-r? (I think they probably do want m-s-r, but
 not 100% sure as I don't tend to think from this perspective very often)
 and I could probably relatively easily code m-i-r to detect if m-s-r is
 in use and take appropriate action depending on that.

Yes, I am pretty sure that keeping m-s-r and m-i-r seperate is very
useful for embedded folks where a UI for switching streams mit be
missing and where hence automatic selection is crucial and manual
configuration impossible.

  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.
 
 Indeed. You've not specifically mentioned the fact that I'm really
 proposing three priority/history lists (per-app, per-role, default) that
 should be checked in order so I'm not sure how signed up you are to that
 idea overall, but the general principles at play here are certainly not
 much different.

This is actually a point I am firmly against. This would basically
mean that the key we read data from the database with might be a
different one from the key we store data in the database with.

Also, just think of the use cases. if I look at my setup here: i have
a bt headset for voip, internal laptop speakers for event sounds and
my hifi via spdif for music/video. That means the output ports I
choose by the role of the audio streams I play. However, you are
suggesting to save/restore stuff primarily per-app. That would mean
Rythmbox and Banshee would get saved/restored devices
independantly. But that simply makes no sense. I am pretty sure you'll
find very few people on this world who have two hifi decks, one for
the stuff they play with banshee and another one for the stuff they
plan with rhythmbox.

Note that this all is for picking good defaults only. Whatever we pick
by default, the user can still manually override. So even if there in
fact do exist weirdos who want to pass rb audio to hifi #1 and banshee
audio to hifi #2, they can still configure things manually and it will
work. Of course, we won't automatically save/restore these settings
for them, but I can live with leaving those weirdos out in the
cold. They are not the common case, they are the exception.

So, I really don't see the use case here, and I am concerned about
using different keys for the db reads and writes.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart

Re: [pulseaudio-discuss] [PATCH] new virtual-sink and virtual-source modules

On Tue, 16.02.10 22:19, pl bossart (bossart.nos...@gmail.com) wrote:

 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

I presume you are talking of the ALSA sink/source stuff?

At FOSDEM I sat down with a couple of gst folks to discuss how to best
integrate echo cancellation and the like into our stack. And so, the
result of those discussions was basically what you are asking for I guess:

The same way as the OSS module drives both the sink and the source of
the same card from the same IO thread we probably should drive ALSA
sinks and sources of the same card from one single thread as well.

Implementing this most likely is an exercise of copy'n'pasting things
around and renaming a few things, and will a be a bit more complex
than the OSS case since we actually might end up driving more than one
sink and more than one source from the same thread. But beyond that it
should be a relatively easy thing to do.

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] playback latency information

On Fri, 22.01.10 15:26, pl bossart (bossart.nos...@gmail.com) wrote:

 This is probably a question for Lennart...
 
 I am somewhat confused on how the playback latency should be
 estimated. I was under the impression that pa_stream_get_latency() was
 the way to go, but I came across some code in gstreamer/pulsesink
 where the latency is retrieved with pa_stream_get_timing_info()

The gst driver used to do things like that when I wrote it. Wim might
have changed that, when he made some major changes to it.

 I however cannot figure out what the fields pa_timing_info::sink_usec
 and ::configured_sink_used mean, and whether they have any
 relationship with the values returned by pa_stream_get_latency(). In
 my tests, I see the following values in the latency_cb() routine

configured_sink_usec is mostly informational. If a client asks for a
specific latency, then this has an effect on the latency the sink is
configured to. This parameter will tell you to which.

Normally the actually measured sink latency should always stay below
the configured_latency, but that is mandatory, because the configured
latency actually configures the playback buffer size and sink_usec
includes the entire sink latency, including any additional latencies
behind the playback buffer.

 sink latency 0, configured_sink_usec 9 sink_usec 0
 sink latency 0, configured_sink_usec 9 sink_usec 87213
 sink latency 0, configured_sink_usec 9 sink_usec 86998
 sink latency 0, configured_sink_usec 9 sink_usec 86724
 sink latency 242259, configured_sink_usec 9 sink_usec 88696
 sink latency 482473, configured_sink_usec 9 sink_usec 88568
 sink latency 473523, configured_sink_usec 9 sink_usec 90064
 sink latency 477102, configured_sink_usec 9 sink_usec 89338
 
 Which of these three values shall be provided to the gstreamer (or
 other middleware) pipeline to represent the back-end delay?

Generally clients should not try to outsmart PA and depend on
_get_latency() or _get_time() for timing which will distill the timing
from all timing information available.

The configured_sink_usec is only an unreliable indication about the
range sink_usec will be in.

sink_usec will contain the latency of the hardware playback buffer,
and all buffers behind it in the hardware, but not include the
per-stream playback buffers or anything that is currently in flux.

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] [SOLVED] Re: No sound output after upgrade

On Sun, 24.01.10 22:03, David Björkevik (da...@bjorkevik.se) wrote:

 --- a 2010-01-24 20:53:23.288259727 +0100
 +++ b 2010-01-24 20:53:15.762260385 +0100
 @@ -147,20 +147,20 @@
  Simple mixer control 'Multi Track Peak',0
Capabilities: volume penum
Playback channels: Front Left - Front Right - Rear Left - Rear
 Right - Front Center - Woofer - Side Left - Side Right - Rear Center
 - ? - ? - ? - ? - ? - ? - ? - ? - ? - ? - ? - ? - ?
Capture channels: Front Left - Front Right - Rear Left - Rear
 Right - Front Center - Woofer - Side Left - Side Right - Rear Center
 - ? - ? - ? - ? - ? - ? - ? - ? - ? - ? - ? - ? - ?
Limits: 0 - 255
 -  Front Left: 39 [15%]
 -  Front Right: 28 [11%]
 +  Front Left: 0 [0%]
 +  Front Right: 0 [0%]
Rear Left: 0 [0%]
Rear Right: 0 [0%]
Front Center: 0 [0%]
Woofer: 0 [0%]
Side Left: 0 [0%]
Side Right: 0 [0%]
 -  Rear Center: 142 [56%]
 -  ?: 152 [60%]
 +  Rear Center: 119 [47%]
 +  ?: 110 [43%]
?: 0 [0%]
?: 0 [0%]
?: 0 [0%]
?: 0 [0%]
?: 0 [0%]
 
 Apparently, PulseAudio mutes the Multi Track Peak control. I did
 not catch this earlier, since that channel appear frozen in the
 alsamixer UI.

Umpf. We don't touch that control. In fact I have never heard of it at
all.

What is very interesting is that this mixer control appears to
properly do multichannel audio. This is an exception, and even for
multichannel cards ALSA drivers tend to implement multiple seperate
stereo sliders for front, rear, surround and so on.

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 Wed, 17.02.10 14:38, pl bossart (bossart.nos...@gmail.com) wrote:

 
  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.
 
 Additional information:
 - paplay file.wav does not start, the start callback isn't called

Oh, indeed. I can reproduce this here. 

/me goes and tries to figure out what is going on.

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 Wed, 17.02.10 23:39, Lennart Poettering (lenn...@poettering.net) wrote:

 
 On Wed, 17.02.10 14:38, pl bossart (bossart.nos...@gmail.com) wrote:
 
  
   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.
  
  Additional information:
  - paplay file.wav does not start, the start callback isn't called
 
 Oh, indeed. I can reproduce this here. 

Actually that was a false alarm. Doesn't actually happen here. The
.wav file I tested was simply very long.

Does it happen for you with any kind of wav file? on all devices?

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 Wed, 17.02.10 23:53, Lennart Poettering (lenn...@poettering.net) wrote:

So, yes, I actually meant what I did in fb55798a... Now the question
is why this doesn't work for Pierre.
   
   Additional information:
   - paplay file.wav does not start, the start callback isn't called
  
  Oh, indeed. I can reproduce this here. 
 
 Actually that was a false alarm. Doesn't actually happen here. The
 .wav file I tested was simply very long.

Nah, strike that. I actually can repriduce this now, for real.

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] On-the-fly changing of sinks or sources in combine- and loopback-modules? Sound-distortions at the beginning of module-loopback?

On Thu, 18.02.10 00:09, Peter Kornatowski (pk...@gmx.net) wrote:

 Hello,
 
 1. Is it possible to change the sinks or sources in an already
 loaded module-combine or module-loopback without unloading and
 reloading the module?

Unless otherwise configured module-combine will automatically add all
new hardware sinks to its outputs and drop those which go away. So
this automatism does allow sinks/sources to be added
dynamically/removed dynamically during runtime. However, there is no
user API for that to trigger that in any way but by
unplugging/plugging hardware.

The streams module-loopback uses you can move around with pavucontrol
or a similar tool.

 2. I also have a problem with sound distortions (mostly much higher
 and quicker voice) several seconds after loading the
 loopback-module (source is a bluetooth-headset and sink is my
 soundcard). After some seconds the distortions disappear and
 everything is fine. I found out that reducing the adjust_time
 parameter of the loopback-module (I had to add adjust_time to
 valid_modargs in the source code) also reduces the duration of the
 distortions, but even at adjust_time=1 they remain for about 2
 seconds (and pulseaudio uses much more CPU). Setting it to 0 doesn't
 work at all.

Sounds as if there is something wrong with the device speed. which
causes PA to compensate by resampling things.

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 Wed, 17.02.10 23:57, Lennart Poettering (lenn...@poettering.net) wrote:

 
 On Wed, 17.02.10 23:53, Lennart Poettering (lenn...@poettering.net) wrote:
 
 So, yes, I actually meant what I did in fb55798a... Now the question
 is why this doesn't work for Pierre.

Additional information:
- paplay file.wav does not start, the start callback isn't called
   
   Oh, indeed. I can reproduce this here. 
  
  Actually that was a false alarm. Doesn't actually happen here. The
  .wav file I tested was simply very long.
 
 Nah, strike that. I actually can repriduce this now, for real.

OK, fixed now:

http://git.0pointer.de/?p=pulseaudio.git;a=patch;h=19fa81bf1375032cb1a27c7715a28a52b238d4cb

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] Need assistance debugging symptom of pacmd spinning during suspend-to-ram attempt

On Fri, 15.01.10 23:02, Daniel Chen (seven.st...@gmail.com) wrote:

 
 On Fri, Jan 15, 2010 at 12:21 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
  Well pacmd isn't really a regular PA client it connects via a
  different IPC mechanism. It would be better to use pactl here I believe.
 
 Right, it would be preferable to use pactl (which would need patching).
 
  Regardless I'm not too sure what is happening here that would be
  different to before. Perhaps the fix for #771 (not accessing the mixer
  when not the active user) is at fault here.
 
 It turned out to be a brown paper bag bug, using pacmd foo instead of
 echo foo|pacmd.

Hmpf. Both commands should be equivalent actually. If you can make one
hang with 100% CPU then this is certainly a bug we need to fix. Can
you tell me how to reproduce this without having to install Ubuntu and
suspend it?

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] General Pulse audio async api questions

On Sat, 16.01.10 17:39, Forwind info (forw...@forwind.net) wrote:

 Understood. One question re headphone operation - when is jack-sensing
 expected in PA ?

When ALSA did the groundwork and we have a usable API we can build on.

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] Need assistance debugging symptom of pacmd spinning during suspend-to-ram attempt

On Fri, 15.01.10 11:24, Daniel Chen (seven.st...@gmail.com) wrote:

Hi,

For the latest stable-queue branch, at
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/507941
there's a report of pacmd consuming 100% CPU when suspending-to-ram.
It seems to be triggered by running the pm-utils script at
http://bazaar.launchpad.net/~ubuntu-core-dev/pulseaudio/ubuntu/annotate/head%3A/debian/01PulseAudio
. Is there something blatantly incorrect in the use(s) of pacmd in
that script, or should we consider a pacmd regression?

(History of said pm-utils script: it's an attempt to mute all sinks
and sources prior to suspending so that speakers/headphones don't pop.
Upon resume the script attempts to restore the existing, i.e., prior
to suspend, user sink and source state. While I realize that the
popping on suspend is really a linux issue, and my patches to fix
those for several HDA codecs have landed in upstream alsa-driver, the
work is not complete.)

BTW, I'd prefer if you would work with the upower/gpm folks to add
some kind of API so that PA can be notified before we go into a
suspend.

Synchronously changing to user priviliges to execute the pacmd script
is insecure business, since user code might actually block your script
indefinitely, which is kinda risky since some machines don't survive if
you close the lid but continue to run full power. Notification to user
software of suspends needs to happen asynchronously/be timeouted
globally. And the place to implement that is upower/gpm.

From PA's point of view suspending the device before we go into sleep
mode is actually the right thing, not so much to work around driver
bugs, but simply because this would be very helpful for our timing
estimation, since a system sleep actually means a prolonged gap in the
wallclock time whre we aren't scheduled. It would clean if we could be
notified about that and suspend our timing interpolation temporarily.

So, I think the goal what you are trying to do is a good, but I am not
happy about the way you implemented it.

Any assistance debugging the symptoms is much appreciated.

An strace would be good.

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] Need assistance debugging symptom of pacmd spinning during suspend-to-ram attempt

On Wed, 17.02.10 20:14, Daniel Chen (seven.st...@gmail.com) wrote:

 
 On Wed, Feb 17, 2010 at 8:04 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  Hmpf. Both commands should be equivalent actually. If you can make one
  hang with 100% CPU then this is certainly a bug we need to fix. Can
  you tell me how to reproduce this without having to install Ubuntu and
  suspend it?
 
 To be more precise, apparently:
 
 echo dump |pacmd
 
 results in pacmd waiting for additional input, whereas:
 
 pacmd dump
 
 does not (exits cleanly to shell). Hopefully this isn't a(nother)
 brown paper bag usage on my part?

I can reproduce this here. Looks I should be wearing the the paperbag
since I broke the pipe thing when I made the command line thing work.

/me goes and fixes that.

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] Need assistance debugging symptom of pacmd spinning during suspend-to-ram attempt

On Thu, 18.02.10 02:26, Lennart Poettering (lenn...@poettering.net) wrote:

 I can reproduce this here. Looks I should be wearing the the paperbag
 since I broke the pipe thing when I made the command line thing work.
 
 /me goes and fixes that.

Done now:

http://git.0pointer.de/?p=pulseaudio.git;a=patch;h=6e064d1d6d0292d230c752b1f41034fd0754487b

Would be awesome if you could test that!

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, 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] 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

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] [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] [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] Canonical Pulse Audio position

2010-02-12 Thread Lennart Poettering

On Fri, 12.02.10 16:00, Conor Curran (conor.cur...@canonical.com) wrote:

 Hi all,
 
 A new position has come up at Canonical (ubuntu) for a sound
 software engineer.
 Details can be found online at :
 
 http://webapps.ubuntu.com/employment/canonical_UDSE/
 http://webapps.ubuntu.com/employment/canonical_UDSE/

Uh, is that position any different from the one that was opened last
April or so, where I even recommended a handful of good people to you
who you all didn't want and who then went on and joined the Collaboras
and Nokias of this world?

That said, I'd of course be very happy if you find someone this time!
We can use every bit of additional manpower!

(If you want, feel free to add this job opening to the News section on
pulseaudio.org. It's a wiki, so just go ahead and edit it (need to reg
first, to combat spam), I can only encourage you to and you get my
blessing that this is a welcome thing to do)

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] My default sound devices are not retained after suspend or reboot

2010-02-11 Thread Lennart Poettering

On Thu, 11.02.10 10:12, Sebastien PIMENTA (p...@pulsradio.com) wrote:

Your mailer is broken.

 Lennart : concerning the card indexes, I'm not sure how to use the
 control device name, like you said.  One of my problem is that I use
 darkice for recording and broadcasting and its conf file is set up
 to record hw(1,0). If I don't edit /etc/modprobe.d/alsa-base.conf to
 fix the sound card order, darkice will record the wrong audio card
 after a reboot or suspend, because the card order changes.

Not sure what darkice is. But configuring it to hw:1,0 is a bad
idea. You should not use the low-level hw:xxx access mode, unless
you really know what you are doing. Use the higher level front:xxx
or so. Also, don't specify more than the card identifier, i.e. don't
use front:xxx,yyy, use front:xxx. Finally, as I already mentioned,
use device names, or control device node paths for opening. Such as:
front:Intel, or front:/dev/snd/by-path/pci-:00:1b.0 or
suchlike.

This will make things much more robust and independant of device index
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] system-wide daemon

2010-02-11 Thread Lennart Poettering

On Thu, 11.02.10 02:01, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 
 'Twas brillig, and Jeremy Nickurak at 11/02/10 01:48 did gyre and gimble:
  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're an admin you'd simply su to the active user and use their
 access credentials to access their PA system.

Also, one could make your admin user member of the audio group, and
access the audio device regardless of who's logged in -- but potentially
you'll clash with a running PA/audio app which already has the device open.

Or, at a higher level you could configure /etc/pulse/default.pa's
module-native-protocol-unix to use an auth-group even when running
in per-session-mode. All user session should then pick that up and
members of that group will always be allowed access.

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] Behavior of pa_threaded_mainloop_wait ()

On Tue, 09.02.10 20:41, Tristin Celestin (tristin_celes...@yahoo.com) wrote:

 Why do I have to explicitly check inside the loop to see if the
 stream is ready, and then break? Do I have to have called wait()
 while the callback executes?

To express in a little different words what Colin already said:

Each _wait() invocation in your control thread will sleep until the
next _signal() call from your IO thread. Since your state callback
probably calls _signal() on each context state change this means that
when you are already connected and then call _wait() again you will
stay stuck, because then no more state changes will happen (unless the
connection is terminated, maybe because a cable was unplugged or so)
and hence no _signal() calls either.

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] How to get pulseaudio streaming to PS3?

On Sun, 07.02.10 16:35, Nyall Dawson (ny...@zombiepigs.net) wrote:

 Hi all,
 
 I remember reading a while back that pulseaudio can use Rygel to
 stream audio to a PS3, but I haven't had any luck finding any how-tos
 or instructions for how to get this working. WIth rygel installed I
 see an option to change the default sink to DLNA/Upnp Streaming, but
 setting this option doesn't give me any audio from the ps3. Am I
 missing something here or is there additional setup I should do to get
 this working?

Basically you need to check the upnp check box in paprefs, and run
rygel with its external dbus provider enabled (which is enabled by
default iirc). And that should be everything that is necessary.

That said, I haven't run this in a while, and never tested this
against the PS3 so this might not work perfectly.

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] My default sound devices are not retained after suspend or reboot

On Sun, 07.02.10 15:11, Sebastien Pimenta (p...@pulsradio.com) wrote:

 Hello,
 
 I'm using ubuntu karmic 9.10 with 2 sound cards and a webcam listed
 below :

Next time, please follow this if you have problems with Ubuntu:

http://pulseaudio.org/wiki/UbuntuBugs

 To explain things better, I've made some screenshots :
 http://box10.pulsradio.com/~pim2/pulseaudiout1.png = my settings for
 output before suspend (default output = SB0404 == what I want). These
 settings seem to be retained after suspend or reboot.
 http://box10.pulsradio.com/~pim2/pulseaudioin1.png  = my settings for
 input before suspend (default input = Audio intern - Line In= == What I
 want.
 http://box10.pulsradio.com/~pim2/pulseaudioin2.png  = my settings for
 input after suspend (default input changed to EMU404 - Microphone)
 This is just an exemple because sometimes after reboot, default input is
 still Intel but switched to mic-in instead of line-in.

Hmm, my educated guess is that some weird suspend script might
unload some device/driver on suspend and reload it afterwards. In PA
this might cause a different default device to be chosen.

You might be able to find out more by enabling debug logging in PA and
then checking syslog. (log-level=debug in /etc/pulse/daemon.conf)

 Maybe it has nothing to do with this problem but I've
 edited /etc/modprobe.d/alsa-base.conf in order to have always the same
 order :
 options snd-emu10k1 index=0
 options snd-hda_intel index=1
 options snd-usb_audio index=2

That is definitely a bad idea, but probably not the cause of this
issue. Stable card indexes are a thing of the past, as it breaks
hotplugging. There is also no need for it, as you can use card names
(as listed in /proc/asound/cards in the []), or you can use the
control device name, such as
hw:/dev/snd/by-path/pci-\:00\:1b.0. Both of which are way more descriptive.

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 Sun, 07.02.10 22:54, Bill Cox (waywardg...@gmail.com) wrote:

 Finally, disable group-based authentication to use the sound system.
 Edit /etc/pulse/system.pa.  Find the line that reads:
 load-module module-native-protocol-unix
 and change it to read:
   load-module module-native-protocol-unix auth-anonymous=1

It's much easier and safer to simply add all users to the
pulse-access group instead of doing dirty security hacks like this.

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, 09.02.10 03:16, Markus Rechberger (mrechber...@gmail.com) wrote:

 
 On Tue, Feb 9, 2010 at 3:01 AM,  olin.pulse@shivers.mail0.org wrote:
  Bill Cox:
  While the right way is not system-wide mode, in practice, I find
  system-wide mode to be very stable and usable on Ubuntu systems that
  have multiple users trying to send sound to the speakers.
 
  So, I'm still wondering: what *is* the right way for this use case? Is it
  the case that PulseAudio just doesn't address it?
 
 There is no right way pulseaudio was not designed to support multiple
 users at the same time (without the depreciated exception of running
 it as system wide daemon).

Not true.

Firstly, what we don't support is simultaneous playback on the same
device by multiple different users, unless you reconfigure
things. Which is the same as for traditional alsa dmix.

Secondly, the system wide mode is not deprecated. It's just not
recommended for use for multi-user systems. It's fine on headless
devices, or on thin clients, where no local user exists.

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 Mon, 08.02.10 21:01, olin.pulse@shivers.mail0.org 
(olin.pulse@shivers.mail0.org) wrote:

 
 Bill Cox:
  While the right way is not system-wide mode, in practice, I find
  system-wide mode to be very stable and usable on Ubuntu systems that
  have multiple users trying to send sound to the speakers. 
 
 So, I'm still wondering: what *is* the right way for this use case? Is it
 the case that PulseAudio just doesn't address it?

On a headless system, or on a system where no local users exist
(i.e. thin clients), use the system-wide mode. On multi-user systems,
don't.

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