Re: [pulseaudio-discuss] Documentation update?

[Nikolai Beier]

2008/5/6 Lennart Poettering <[EMAIL PROTECTED]>:
> On Wed, 30.04.08 13:56, Nikolai Beier ([EMAIL PROTECTED]) wrote:
>
>  > Hello all.
>  >
>  > I noticed that http://pulseaudio.org/wiki/Modules mentions the module
>  > "module-detect" is mentioned two time. Perhaps the two entries should
>  > just be merged?
>
>  I guess you already noticed that the site is a wiki and you are very
>  welcome to update it. (at least there's someone called "beier" who did
>  some changes)

Yes. I usually hesitate to write public readable text about things
that I am not sure of. With help from the IRC channel and reading
other sources I tried after all.

>  padevchooser is not going to be continued the way it is right now. I
>  will replace it with something that works differently but exposes
>  basically the same functionality (but based on tunnels instead of
>  direct connections).

That sounds like a really good plan for that tool!

-- 
Nikolai Beier
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Moving sources and sinks

[Lennart Poettering]

On Sun, 04.05.08 14:15, Tanu Kaskinen ([EMAIL PROTECTED]) wrote:

> 
> On Sat, May 03, 2008 at 04:48:05PM -0700, Nick Thompson wrote:
> > Given what you say (above) about per device routing not being possible I 
> > think the area I'd like to concentrate on is figuring out how a module 
> > can detect streams as they are being created.  That way it could get the 
> > call in to switch sink input before the stream is started.  So figuring 
> > this out would be a great start.
> 
> This is how I think it might work:
> 
> 1. Register yourself to listen to new sink input events. The
> pa_core structure (core.h) has an array of hooks, each
> corresponding to one type of event. The following will do
> the registration:
> 
> pa_hook_connect(core->hooks[PA_CORE_HOOK_SINK_INPUT_NEW],
> my_callback,
> my_userdata);
> 
> There the "core" variable is a pointer to pa_core.
> my_callback is a function that gets called when the event
> happens, and my_userdata is pointer to any data you want the
> callback function to have access to.
> 
> 2. Change the destination sink. The callback gets as
> parameters a pointer to pa_core, a pointer to
> pa_sink_input_new_data, and the userdata pointer you gave in
> the registration function. pa_sink_input_new_data has the
> field "sink", which you can set in the callback to be the
> sink you want the sink input to connect to.

This is exactly how it should be done!

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Moving sources and sinks

[Lennart Poettering]

On Sat, 03.05.08 23:55, Tanu Kaskinen ([EMAIL PROTECTED]) wrote:

> > Phew.  Anyway the second question was not really answered fully.  It  
> > might be my imprecision in stating the problem so let me try to  
> > distill it to the bare bones:  For pulseaudio I'd like to know how or  
> > if a virtual stream can be created in pulse allowing on the fly  
> > redirection to an ALSA sink, that is the crux of the question that I'm  
> > searching for an answer.  I'd like in an alsa program (or set of  
> > programs) to write to a virtual device and have pulse route all audio  
> > on that device to a sink, and be able to switch sinks on the fly.   
> > I've spent a couple weeks looking into this and I think I've made  
> > quite a lot of progress but that part is not clear.
> 
> It's not possible with current virtual devices. The virtual
> devices that you can create don't allow their streams (the
> ones from the virtual device to the destination sinks) to be
> moved.

This is an artificial limitation, btw. It's the respective module that
sets the PA_SINK_INPUT_DONTMOVE flag to tell the PA core not to allow
moving of the streams. I added this because it kind of contradicts the
explicit configuration the user gave before. But primarily the reason
is that I was to lazy to implement the code that makes sure that the
sink description follows the move. I.e. that "LADSPA sink on foobar"
changes to "LADSPA sink on waldo" if you move it's stream from foobar
to waldo. Also in the case of module-combine (especially in automatic
mode) moving those backend streams is really pointless.

Patches welcome. I guess I could be talked into dropping
PA_SINK_INPUT_DONTMOVE for the LADSPA and remap sinks if someone
supplies a patch that implements the "description fix" properly.

As I mentioned somewhere else: the right way to do this thing is
writing a small module that hooks into the stream creation and chooses
a device based on the role (or "class" or whatever you call it) of a
stream. A bit like module-match+module-volume-restore+some more
magic. And of course, we'd need to teach all apps to send PA the class
of their streams. A temporary fix is to set the environment var for
PULSE_PROP_media.role to "video", and so one before starting the
client in question. Like this:

  PULSE_PROP_media.role="phone" pacat /dev/urandom
  PULSE_PROP_media.role="music" pacat /dev/urandom

You get the idea.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Moving sources and sinks

[Lennart Poettering]

On Sat, 03.05.08 11:48, Nick Thompson ([EMAIL PROTECTED]) wrote:

> fully accept that my use of pulse might be somewhat unorthodox since  
> it is in a speciailsed embedded system, however I also think that  
> multiple device support and routing is of great interest, especially  
> to the music community.  One of the issues of audio support on  

Actually PA's focus does include embedded stuff, but it doesn't
include music production that much.

As mentioned, policy routing has been requested before, and added most
infrastructure that was necessary to implement it. It's in the
glitch-free banch. The missing bits and pieces are actually minor in
contrast to the infrastructure chnages.

> mainstream OS's like Max OS X is the lack of simultaneous synchronized  
> multiple device support and this is an area where pulse has a great  
> deal of potential.  Since the archives are online one would hope
> that  

Uh, this is not correct Mac OSX does have "aggregate" audio
devices. They never worked for me though.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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 module development

[Lennart Poettering]

On Tue, 06.05.08 01:32, Colin Guthrie ([EMAIL PROTECTED]) wrote:

> Your approach is not really the recommended one. The pulsecore API is 
> not stable and as such isn't installed.
> 
> If you are doing module development, the recommended method is to build 
> it within the pulse tree itself. Simplest way is to do an anonymous svn 
> checkout.

BTW. I am pretty open to create branches for people in PA upstream if
they want and have some code that could go into PA proper. I am also
happy to merge any reasonable patches.

In short: develop modules in-tree. Not out-of-tree. It's a bit like
the Linux kernel. ;-)

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Moving sources and sinks

[Lennart Poettering]

On Fri, 02.05.08 11:27, Matt Patterson ([EMAIL PROTECTED]) wrote:

> So I think what I would do is make a "combined" sink for each class of data 
> that routes all audio to all sources. If you disable the module to gets rid 
> of idle streams this will leave you with active but corked streams to all 
> output devices from each sink. You can then update which streams are muted. 
> If you need to do this literally stream by stream (as in playback event by 
> playback event) this might not work because I am just using the text 
> interface (basically what pacmd is) and would have no way of being notified 
> when a new stream is played. If on the other hand the routing is more 
> global and based on external events you could easily update the current 
> config and then all future sounds would play as expected.

Using the combined sink for this kind of stuff is not a good idea. The
point of module-combine is to deal with sampling rate deviations. It
resamples audio to fix them. If you already complained about CPU
usage, then this is not going to help it.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Moving sources and sinks

[Lennart Poettering]

On Fri, 02.05.08 11:01, Nick Thompson ([EMAIL PROTECTED]) wrote:

> 
> 
> Awesome Matt, if you can share your source I would love to see it.
> 
> What you are doing sounds interesting.
> 
> For my app I'd like to have two classes of data.  For arguments sake  
> these are "normal" and "alert".  Normal audio (mp3, wav, application  
> data) needs to be routed to the currently selected output.  Alert  
> audio, which would include system sounds, tactile feedback and the  
> like, would need to be routed to a different source (and possibly also  
> the default output source as well).  Initially I was looking at some  
> sort of stream tagging mechanism using something like the class filed  
> in ALSA, but this is clunky and I cannot guarantee that all audio will  
> pass through alsa (for example the gstreamer pulse plugin looks  
> interesting for certain apps).  At the moment I'm trying to prototype  
> this on a regular x86 desktop system, later I'll move it to an  
> embedded system, once I've figured out a means to implement it.
> 
> It think the issue I have can be described as follows: based on my  
> current understanding I would need to track every stream to determine  
> where to route it.  I'd like to cluster my normal and alert streams  
> together and route them all en-masse to a sink.

As mentioned, in the glitch-free branch you have those properties you
can attach to each stream. To implement policy routing a module should
be written that hooks into the stream creation code (similar to what
module-volume-restore already does) looks for the "class" property and
adjusts the sink the stream is attached to properly.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Moving sources and sinks

[Lennart Poettering]

On Fri, 02.05.08 10:37, Matt Patterson ([EMAIL PROTECTED]) wrote:

> I do agree that coding for pulse can be a steep learning curve, which is 
> why I opted to build all my solutions by simply connecting to the text mode 
> control socket and sending commands/parsing text output. I have built what 
> is essentially a multiplex audio switch allowing any of x number input 
> sources to play out of any x number of output sinks, all controlled via a 
> python or php app.

BTW. Some people seem to assume that I as the author PA do believe
that the native PA API is the best thing ever invented. Be assured: I
don't think so. It is powerful, and not redundant, but it is
admittedly hard to use due to its asynchronous nature.

However, I do have a plan to fix this.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Moving sources and sinks

[Lennart Poettering]

On Fri, 02.05.08 10:20, Nick Thompson ([EMAIL PROTECTED]) wrote:

> OK so I figured out the error of my ways, but I have to say this list is 
> pretty unresponsive in helping the community so I have to ask myself "is 
> pulse is a sensible choice for audio development today"?   Particularly 
> since there is little in the way of useful setup documentation for actually 
> using the library on a programatic way, the error messages from the library 
> and utilities are not particularly helpful and so on.

Yes, our documentation is not perfect. Nothing is perfect. But
complaining about Free Software like this doesn't really make you any
friends in the community, you know? This is not how Free Software
works.

Our resources are not infinite. Actually they are very much finite,
it's only me who works on PA full-time. All other contributors do it
in their spare time or supply only patches from time to time.

Also, coling and tanuk and others do a very good job with responding
on this mailing list (and I am very thankful for what they are
doing. Thanks, dudes!). I am not constantly monitoring this
list. However, I try my best to respond to every single post that is
left unanswered, from time to time. So please be patient, eventually
most people should get an answer from me, even if it might take a while,
like this reply did. 

In short: we're not your support monkeys! Thank you very much.

> What I need to be able to do is route audio around.  I suspect write a 
> module for pulse that will look at the alsa stream class and based on that 
> use the input index to set the sick for that stream.  It would be nice to 
> have a feature whereby I can rout all output sent to a particular sink, to 
> another sink.  I guess what I'd like to do is be able to create virtual 
> devices whose output can be changed on the fly.  So for example I could 
> define an mp3 output that I can switch between headphone output and speaker 
> output depending on a system setting.  Or between one speaker output and 
> another.  If pulse has a means to do this already I'd appreciate someone 
> pointing me in the direction that can help.

Something like this has been asked for before.

In the glitch-free branch in SVN you'll find a "proplist" feature that
allows you to attach all kinds of meta information to streams, sinks,
sources, clients. One of the reasons to add this is to allow
implementation of policy routing like you suggest.

> It seems ALSA will do most of this and the ALSA list seems to be a lot more 
> active, so maybe I was mistaken in thinking that Pulse would really be a 
> useful addition to our audio stack, particularly since on an embedded 
> system it consume disproportionate resources for the benefit it
> provides.

Oh come on, dude. You make it sound like I should feel bad because you
won't use my software. I am not sure in what strange a world you
live. You should be thankful that the Free Software people allow you
to use your software for free -- no the other way around. And for
fuck's sake, if there's something that the software you are interested
in lacks, then please stop complaining and supply a patch. That is how
free software works.

Also, if you don't need PA, then don't use it. Nobody forces
you. Especially in embedded space you should really know if you need
something before you add it to your stack. I am happy for every
complaint I get less from people with no clue about open source like you.

> Also where is the mixer implemented and how is it controlled.  Or is the 
> mixer just a dumb "you have 3 streams coming in and I will make them one" 
> type deal.  In other words is there bussing or output switching in the 
> mixer.  If not, is this planned?

I am not sure I get what exactly you are asking for. But yes, PA mixes
audio. Surpised? 

> Anyway, in case this helps anyone else, the sources that are listed by 
> list-sources are not really sources to pulse.  So trying to move them 
> around will not work.  Here's something I wrote up on the subject:

I think you didn't understand the distinction PA makes between sinks
and source-outputs, resp. sources and sink-inputs. I.e. clocked
vs. non-clocked.

Please shut up with your complains. Learn how Free Software works. 

I don't take complains. I only take patches, suggestions and bug reports.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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 module development

[Colin Guthrie]

Nick Thompson wrote:
> On the page on the wiki about developing modules at:
> 
> 
> 
> There's a nifty little tutorial on writing a plugin.  Handy stuff.   
> The pulsecore headers are all referenced with prefix "pulsecore", as in:
> 
> #include 
> 
> I fished around for any pulse related -dev pkgs that I had not  
> installed, but nothing obvious showed up in Synaptic.
> 
> So I copied the pulsecore directory from the pulse sources to /usr/ 
> include and deletec the c files. I also needed to copy the config.h  
> file from the pulse directory to /usr/include/pulsecore
> 
> My test plugin builds and loads.
> 
> Am I missing a package or is the method outlined above the way to go  
> (it works on my machine(tm) :)

Your approach is not really the recommended one. The pulsecore API is 
not stable and as such isn't installed.

If you are doing module development, the recommended method is to build 
it within the pulse tree itself. Simplest way is to do an anonymous svn 
checkout.

/me now wishes he'd read that page before embarking on writing his 
current module ;)

Col

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Documentation update?

[Lennart Poettering]

On Wed, 30.04.08 13:56, Nikolai Beier ([EMAIL PROTECTED]) wrote:

> Hello all.
> 
> I noticed that http://pulseaudio.org/wiki/Modules mentions the module
> "module-detect" is mentioned two time. Perhaps the two entries should
> just be merged?

I guess you already noticed that the site is a wiki and you are very
welcome to update it. (at least there's someone called "beier" who did
some changes)

> Then there is the use of the word default, and how to set it up.
> especially in th padevchooser where one can set the default to
> default, but not see what the default is!

padevchooser is not going to be continued the way it is right now. I
will replace it with something that works differently but exposes
basically the same functionality (but based on tunnels instead of
direct connections). 

But yes, there's always room for improvement. Our docs are, humm,
limited -- and not up to date. 

I'll try to update them after I made the next release which is my top
prio right now.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Pulse module development

[Nick Thompson]

On the page on the wiki about developing modules at:



There's a nifty little tutorial on writing a plugin.  Handy stuff.   
The pulsecore headers are all referenced with prefix "pulsecore", as in:

#include 

I fished around for any pulse related -dev pkgs that I had not  
installed, but nothing obvious showed up in Synaptic.

So I copied the pulsecore directory from the pulse sources to /usr/ 
include and deletec the c files. I also needed to copy the config.h  
file from the pulse directory to /usr/include/pulsecore

My test plugin builds and loads.

Am I missing a package or is the method outlined above the way to go  
(it works on my machine(tm) :)

Thanks

Nick
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio on maemo/n800

[Lennart Poettering]

On Tue, 29.04.08 22:48, Colin Guthrie ([EMAIL PROTECTED]) wrote:

> 
> Kwan Hong Lee wrote:
> > The files /var/run/pulse nor /tmp/pulse-user are not created at all.  I
> > manually create them, but that does not help either.
> > 
> > Maybe it's because it's tmpfs.  Is there any way to change this?
> 
> I wouldn't have thought tmpfs would have problems, but try putting some
> more logging around the lines of code I pointed at earlier and that may
> give you more insight as to what is really wrong.

/me would recommend an "strace".

tmpfs should be fine for this kind of stuff, actually. Unless the
access mode of /tmp/ are set up weirdly.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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 on maemo/n800

[Lennart Poettering]

On Tue, 29.04.08 11:59, Jim Carter ([EMAIL PROTECTED]) wrote:

> > > user$ pulseaudio
> > > W: core-util.c: setpriority(): Permission denied
> > > E: main.c: Failed to create '/tmp/pulse-user': Permission denied
> > 
> > Can you create the folder /tmp/pulse-user yourself? Can you chown and
> > chmod OK on the filesystem? Perhaps it is a FAT filesystem and pulse is
> > failing because the chown/chmod is not working? (not looked at the code
> > for a while so not 100% sure on that one).
> 
> The filesystem for /tmp is tmpfs, and for the main flash disc is jffs2.  
> But the expansion flash "discs" are typically vfat, hiss, boo.  
> 
> If /tmp/pulse-user had already been created as root, probably mode 700, 
> that would explain the second "permission denied".  Pick one style, remove 
> the directory, and likely everything will be fine.  

This is btw a very good DoS attack for PA. It now has been fixed in
the glitch-free branch in SVN.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] SHM Error Messages

[Lennart Poettering]

On Sun, 20.04.08 21:04, Jim Duda ([EMAIL PROTECTED]) wrote:

> I don't know what I have done now, but suddenly sound stopped working on 
> my desktop fc8 computer.  I must have changed some setting ...
> 
> I'm getting this message in /var/log/messages whenever I try to play 
> anything.  Can anyone tell me what this message indicates?
> 
>   pstream.c: Recieved SHM frame on a socket where SHM is disabled.

Yepp. this is some issue in PA. I am the one to blame. I think there's
even a bug filed about this. The PA client code makes different
assumptions after auth then the server code does. You probably
triggered this by accessing PA from different user ID?

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Re : Effects of Clock Resolution on Pulseaudio

[Lennart Poettering]

On Fri, 18.04.08 17:12, DSK ([EMAIL PROTECTED]) wrote:

> > Most likely someone needs to spend some time to optimize the inner
> > loops (mixing, resampling, converting)  a bit better for ARM.
> 
> Well the observations taken are when a single 44K file is being played with
> pacat ..  (so no resampling, mixing or converting comes into picture) ...
> 
> So i am not sure what part of Pulseaudio is causing high CPU Utilization ..

Hmm, could you do some profiling then? Just the most basic. I.e. what
functions take up most CPU.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Uber-early glitch-free Testing Results

[Lennart Poettering]

On Wed, 16.04.08 16:13, Sean McNamara ([EMAIL PROTECTED]) wrote:

> * PA should not run with --system (as 'pulse' user) because you
> can't use SHM transfer, you have to tweak PolicyKit to allow real-time
> scheduling to the 'pulse' user, and because you have to add all
> desired users (of the -unix protocols) to the 'pulse-access' group.

I guess packagers should simply add the "pulse" user to the "pulse-rt"
group by default, if they ship support for system mode.

> who want access when the user logs off. Test it: start pa with
> --daemonize=true and as a regular user, then log off the session.
> Poof, PA gone.

Nah. That's not true. It might be that you the X11 modules
loaded. libX11 has this annoying behaviour of terminating the
application if the X connection ends. If you don't load those modules
(or if you unload them before detaching) PA should stay running.

> So it seems the 'pulse' user needs to be *made* to be able to use shm
> ;-) Is there any way to feasibly do that?

Oh, SHM support in system-mode PA is disabled because I added specific
code to disable it. If you drop that check PA is perfectly able to do
SHM in system mode.

The thing is simply that SHM exposes far too much information about
PA's internal memory management to other processes. Funneling
everything through a single kernel-controlled socket is good security
gateway if you want to speak with processes you don't trust. Far
better then giving them access to all your internal memory management
data and more.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Can I mute rtp-recv somehow?

[Lennart Poettering]

On Sun, 13.04.08 17:36, Jim Duda ([EMAIL PROTECTED]) wrote:

> Is there a method I can use to mute the audio coming into a server via 
> rtp-recv?

Turn down the volume of all RTP streams with pavucontrol.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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 with Motif?

[Lennart Poettering]

On Mon, 14.04.08 15:45, Rémi Cardona ([EMAIL PROTECTED]) wrote:

> >> You should, however, *NOT* only implement a pulse backend in your
> >> application. Put an abstraction layer in between to allow to add
> >> direct ALSA and ESD access, too.
> > 
> > If I wanted to do that, I would have kept SDL. Is there some flaw in 
> > pulseaudio that makes it less suitable than ALSA or ESD? And IIRC 
> > neither has an asynchronous API (admittedly I did not look very hard; I 
> > would like to avoid having to master more than 1 sound API).
> 
> Well, maybe if someone already wrote code for Motif apps to use ALSA, 
> that might be easier. The ALSA API is quite stable now, while Lennart 
> has said not so long ago (in the Skype-wanting-to-use-PA-natively 
> thread, IIRC) that the PA API could change.

The thing about the PA API is that it is very difficult to use, due to
its fully asynchronous design. It is a bit too low-level.

The native PA API will stay around and also be as stable as
possible. However for the future I hope that some kind of audio API
that sits on top of PA and other backends will take the place of the
API all people program against and that we then can drop all those
seperate abstraction layers all those applications currently ship
with. I.e. the native PA will have a position akin to libX11, and we
need something on top of that, akin to libgtk. (And yes, I am working
on that and it is called libsydney, but it's not ready yet)

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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 with Motif?

[Lennart Poettering]

On Mon, 14.04.08 14:17, Michel Bardiaux ([EMAIL PROTECTED]) wrote:

> > See the point? There's no connection between Pulseaudio (specifically
> > its client library) and a given widget set. 
> 
> Actually, there is. I had done some amount of research, and had looked 
> at the sample clients on pulseaudio.org, and it was clear (eg from 
> paplay.c) that for pulseaudio one has pa_mainloop_run exactly where an 
> Xt application has XtAppMainLoop. In single-thread I can't run both at 
> the same time, which means I have to merge the 2 loops somehow. Your 
> mention of "input loop of my widget" below makes me believe you mean 
> exactly that.

PA provides an abstraction system for event loops. It comes with one
simple implementation (the pa_mainloop) and one that works on top of
GLib. Just implement the structure you find in mainloop-api.h on top of
your specific event loop and you should be fine.

But please remember: driving audio streams from the same thread as the
UI is usually a bad idea. It's Ok to use it for writing control apps
like pavucontrol or suchlike since latency doesn't matter for
them. But for streaming audio, doing the event loop for PA in a thread
that is seperate from the UI event loop is a good idea. (But it all
depends, if you don't care for audio latency at all it could be fine
to drive an audio stream from the UI stream.)

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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 with Motif?

[Lennart Poettering]

On Tue, 08.04.08 17:58, Michel Bardiaux ([EMAIL PROTECTED]) wrote:

> 
> Michel Bardiaux wrote:
> > Any example using PulseAudio for sound and Motif (or Athena) for GUI?
> > 
> > TIA,
> 
> Pretty please?
> 
> I would really like to add networked audio capability to my 
> applications, but finding one's way between NAS, ESD, ARTS, JACK, etc is 
>   hard going. Currently, PULSE looks very attractive because it does not 
> insist on threads, using an asynchronous model instead. Since Motif (and 
> Athena) do the same, the match should be good, but I havent found any 
> example yet. Just a ltle pointer would help a lot.

Uh. I guess Motif is just a bit out of fashion these days, that's all,
that's why noone responded. ;-)

But yes, the PA client can integrate into other event loops. That
doesn't mean however that this is a really go idea in all cases. In
fact in most cases it is not a good idea, especially not if you drive
an X11 GUI whith all kinds of time intensive and blocking syscalls
from the same event loop.

The PA client is very flexible when it comes to event loops. That is
quite nice in some ways, but actually it also makes the PA client APIs
a bitt too complex.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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] Controlling pulseaudio daemon via dbus

[Lennart Poettering]

On Mon, 31.03.08 13:24, Turner, Todd ([EMAIL PROTECTED]) wrote:

> Hi All,
>  
> Are there any plans for a dbus module?   I see that PA uses dbus to
> connect to policy kit, and that there are dbus-util.c file in the
> modules package that appears to be for modules to connect to other
> services like bluetooth or hal, but I am looking for a way for
> applications to send messages to the daemon over dbus.

The thing with D-Bus is that it is not network transparent. While I do
like D-Bus a lot it is thus not really suitable for the PA case. The
native PA APIs are all network transparent, and thus D-Bus is not
really a suitable replacement I would say. And carrying two IPC APIs
around all the time doesn't strike me as a particularly good idea.

Sometime in the far far future I will replace the PA native protocol
by something based on D-Bus-via-TCP together with RTP for the audio
data transfer. But that's something for the future.

Of course, I won't stop you from hacking up a D-Bus module.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
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 pulse bugs

[Sjoerd Simons]

On Mon, May 05, 2008 at 12:22:10PM +0200, [EMAIL PROTECTED] wrote:
> Quoting Colin Guthrie <[EMAIL PROTECTED]>:
> > Actually just having a very quick glance at the Alsa API docs, it
> > doesn't mention that this value should be 0 if there are no samples to play:
> >
> > http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga0d9e14a4be65209eb549e48a9f07302
> >
> > Closest it says is: "It's positive and less than buffer size in normal
> > situation".
> >
> > So perhaps this is an invalid assumption at the wine side?
> 
> However this part:
> 
> Delay is distance between current application frame position and sound  
> frame position.

I'm not an alsa expert. But what application normally want to know from this
call is: If i write some bits of audio *now* how long will it take before it's
played. Which is used for audio/video synchronisation. If you change the pulse
plugin to not report network latency, then audio/video synchronisation will
break.


> suggests that it indeed can be zero. Or why would a soundcard have a  
> gap between the read and write positions if it has played everything?

That it *can* be zero, doesn't mean it *has* to become zero though. The root of
this issue is that you (and the alsa API mostly is too) are assuming to be
talking to a soundcard, but pulseaudio isn't a soundcard. So there are some
subtle differences...

> If Wine uses a wrong assumption, then please clarify the function description.
> 
> > Is there perhaps a more appropriate API call they can use to do whatever
> > test they are doing?
> 
> What Wine needs to know, is whether a particular sample has already  
> been played or not. It does 'bytes_written - delay_in_bytes' to find  
> out how much of the written data the soundcard has already played. If  
> there is a better test for it, please explain.

Don't know, sorry

  Sjoerd
-- 
Ah, but a man's grasp should exceed his reach,
Or what's a heaven for ?
-- Robert Browning, "Andrea del Sarto"
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa pulse bugs

[Colin Guthrie]

[EMAIL PROTECTED] wrote:
>> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga0d9e14a4be65209eb549e48a9f07302
>>
>> Closest it says is: "It's positive and less than buffer size in normal
>> situation".
>>
>> So perhaps this is an invalid assumption at the wine side?
> 
> However this part:
> 
> Delay is distance between current application frame position and sound  
> frame position.
> 
> suggests that it indeed can be zero. Or why would a soundcard have a  
> gap between the read and write positions if it has played everything?

Indeed. I agree. However, for me this is something that should not be in 
high level documentation, that should be an internal thing (i.e. it's a 
detail of the implementation). It's perfectly true of hardware devices 
(no doubt the context when the docs were written) but perhaps this 
should not be true of non-h/w or ioplug based "devices"? Someone who 
vaguely understands the ALSA stuff should have a better insight on this 
to comment :p

>> Is there perhaps a more appropriate API call they can use to do whatever
>> test they are doing?
> 
> What Wine needs to know, is whether a particular sample has already  
> been played or not. It does 'bytes_written - delay_in_bytes' to find  
> out how much of the written data the soundcard has already played. If  
> there is a better test for it, please explain.

I've no idea, I'm just throwing up ideas/suggestions/opinions... there 
is little technical background from my comments, just trying to raise 
some points so people more familiar than I can comment :)

Take care

Col

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa pulse bugs

[tom]

Quoting Colin Guthrie <[EMAIL PROTECTED]>:
> Actually just having a very quick glance at the Alsa API docs, it
> doesn't mention that this value should be 0 if there are no samples to play:
>
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga0d9e14a4be65209eb549e48a9f07302
>
> Closest it says is: "It's positive and less than buffer size in normal
> situation".
>
> So perhaps this is an invalid assumption at the wine side?

However this part:

Delay is distance between current application frame position and sound  
frame position.

suggests that it indeed can be zero. Or why would a soundcard have a  
gap between the read and write positions if it has played everything?

If Wine uses a wrong assumption, then please clarify the function description.

> Is there perhaps a more appropriate API call they can use to do whatever
> test they are doing?

What Wine needs to know, is whether a particular sample has already  
been played or not. It does 'bytes_written - delay_in_bytes' to find  
out how much of the written data the soundcard has already played. If  
there is a better test for it, please explain.

tom



___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa pulse bugs

[Colin Guthrie]

Colin Guthrie wrote:
> [EMAIL PROTECTED] wrote:
>>> Re the snd_pcm_delay() including network latency (#3945), this clearly
>>> makes sense for network streams. Does you proposed fix include this
>>> delay (albeit with the improvement that it also will drop to 0 if there
>>> are no samples queued)?
>> snd_pcm_delay() should not include any network latency. The API is  
>> defined as 'read pointer - write pointer', and applications expect  
>> that. Or at least they expect that when all samples are played that  
>> the delay drops to zero.
> 
> With the caveat of very limited technical knowledge, I can agree on the 
> latter point (drop to 0 when all samples are played), but if it was 
> implemented sans net-delay in pulse would this not cause e.g. a-v sync 
> issues when playing via alsa to a networked PA server? If so then this 
> fix would introduce another bug.

Actually just having a very quick glance at the Alsa API docs, it 
doesn't mention that this value should be 0 if there are no samples to play:

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga0d9e14a4be65209eb549e48a9f07302

Closest it says is: "It's positive and less than buffer size in normal 
situation".

So perhaps this is an invalid assumption at the wine side?

Is there perhaps a more appropriate API call they can use to do whatever 
test they are doing?

Col

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa pulse bugs

[tom]

Quoting Colin Guthrie <[EMAIL PROTECTED]>:

Attached patches to #3943 and #3944. Please read the comments there.

> [EMAIL PROTECTED] wrote:
>>> Re the snd_pcm_delay() including network latency (#3945), this clearly
>>> makes sense for network streams. Does you proposed fix include this
>>> delay (albeit with the improvement that it also will drop to 0 if there
>>> are no samples queued)?
>>
>> snd_pcm_delay() should not include any network latency. The API is
>> defined as 'read pointer - write pointer', and applications expect
>> that. Or at least they expect that when all samples are played that
>> the delay drops to zero.
>
> With the caveat of very limited technical knowledge, I can agree on the
> latter point (drop to 0 when all samples are played), but if it was
> implemented sans net-delay in pulse would this not cause e.g. a-v sync
> issues when playing via alsa to a networked PA server? If so then this
> fix would introduce another bug.

Your arguments seem reasonable. Let's see what others have to say to  
it. It would be interesting to see how much delay such change  
introduces. I can't test PA over network at home, but if someone  
wants, the patch is attached to the bug entry in the alsa bugtracker.

>>> Also re #3942, I believe (but not sure) that the max buffer in the
>>> glitch free branch has been increased significantly (as it now needs to
>>> keep some degree of past sound as well as future buffer to allow the
>>> rewinds to work properly (this is no doubt an inaccurate description of
>>> why it's needed :p)) I'm not sure how this would affect this
>>> solution, but Lennart will be able to advise better.
>>
>> I'd suggest to export MAX_MEMBLOCKQ_LENGTH in a public API so that
>> applications can make use of it. If the max buffer length has been
>> increased, then the alsa pulse plugin should be able to propagate that
>> to applications using the alsa API.
>
> Well I'm not sure of the internals of the glitch-free stuff, but I doubt
> it's a buffer that can be used in quite the same way as that. Lennart
> will be able to advise if I've got the wrong end of the stick in my
> comments :)

tom


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa pulse bugs

[Colin Guthrie]

[EMAIL PROTECTED] wrote:
>> Re the snd_pcm_delay() including network latency (#3945), this clearly
>> makes sense for network streams. Does you proposed fix include this
>> delay (albeit with the improvement that it also will drop to 0 if there
>> are no samples queued)?
> 
> snd_pcm_delay() should not include any network latency. The API is  
> defined as 'read pointer - write pointer', and applications expect  
> that. Or at least they expect that when all samples are played that  
> the delay drops to zero.

With the caveat of very limited technical knowledge, I can agree on the 
latter point (drop to 0 when all samples are played), but if it was 
implemented sans net-delay in pulse would this not cause e.g. a-v sync 
issues when playing via alsa to a networked PA server? If so then this 
fix would introduce another bug.

>> Also re #3942, I believe (but not sure) that the max buffer in the
>> glitch free branch has been increased significantly (as it now needs to
>> keep some degree of past sound as well as future buffer to allow the
>> rewinds to work properly (this is no doubt an inaccurate description of
>> why it's needed :p)) I'm not sure how this would affect this
>> solution, but Lennart will be able to advise better.
> 
> I'd suggest to export MAX_MEMBLOCKQ_LENGTH in a public API so that  
> applications can make use of it. If the max buffer length has been  
> increased, then the alsa pulse plugin should be able to propagate that  
> to applications using the alsa API.

Well I'm not sure of the internals of the glitch-free stuff, but I doubt 
it's a buffer that can be used in quite the same way as that. Lennart 
will be able to advise if I've got the wrong end of the stick in my 
comments :)

Col

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa pulse bugs

[tom]

Quoting Colin Guthrie <[EMAIL PROTECTED]>:

> [EMAIL PROTECTED] wrote:
>> I reported three bugs to the alsa bugtracker:
>>
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3942
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3943
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3944
>>
>> It's three bugs after all. Once these are fixed I expect Wine to work.
>> *fingers crossed*
>
> Ace Tom :)
>
> I've cross posted this to the alsa devel list. Hopefully Takashi (who's
> committed some pulse-related stuff recently) will have some insight here.
>
> Re the snd_pcm_delay() including network latency (#3945), this clearly
> makes sense for network streams. Does you proposed fix include this
> delay (albeit with the improvement that it also will drop to 0 if there
> are no samples queued)?

snd_pcm_delay() should not include any network latency. The API is  
defined as 'read pointer - write pointer', and applications expect  
that. Or at least they expect that when all samples are played that  
the delay drops to zero.

And no, my current patch does not include network latency at all. It  
simply does what alsa does, 'read pointer - write pointer'.

> Also re #3942, I believe (but not sure) that the max buffer in the
> glitch free branch has been increased significantly (as it now needs to
> keep some degree of past sound as well as future buffer to allow the
> rewinds to work properly (this is no doubt an inaccurate description of
> why it's needed :p)) I'm not sure how this would affect this
> solution, but Lennart will be able to advise better.

I'd suggest to export MAX_MEMBLOCKQ_LENGTH in a public API so that  
applications can make use of it. If the max buffer length has been  
increased, then the alsa pulse plugin should be able to propagate that  
to applications using the alsa API.

tom



___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] alsa pulse bugs

[Colin Guthrie]

[EMAIL PROTECTED] wrote:
> I reported three bugs to the alsa bugtracker:
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3942
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3943
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3944
> 
> It's three bugs after all. Once these are fixed I expect Wine to work.  
> *fingers crossed*

Ace Tom :)

I've cross posted this to the alsa devel list. Hopefully Takashi (who's 
committed some pulse-related stuff recently) will have some insight here.

Re the snd_pcm_delay() including network latency (#3945), this clearly 
makes sense for network streams. Does you proposed fix include this 
delay (albeit with the improvement that it also will drop to 0 if there 
are no samples queued)?

Also re #3942, I believe (but not sure) that the max buffer in the 
glitch free branch has been increased significantly (as it now needs to 
keep some degree of past sound as well as future buffer to allow the 
rewinds to work properly (this is no doubt an inaccurate description of 
why it's needed :p)) I'm not sure how this would affect this 
solution, but Lennart will be able to advise better.

Hopefully he'll have some comments on all of the above bugs as you've 
clearly put in a lot of work to try and nail these issues :)

Col

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] alsa pulse bugs

[tom]

I reported three bugs to the alsa bugtracker:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3942
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3943
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3944

It's three bugs after all. Once these are fixed I expect Wine to work.  
*fingers crossed*

tom


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss