Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

[Marco Ballesio]

Hi,

On Thu, Jul 15, 2010 at 5:35 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Colin Guthrie at 08/07/10 10:40 did gyre and gimble:
 'Twas brillig, and Marco Ballesio at 08/07/10 09:37 did gyre and gimble:
 Hi,

 On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie gm...@colin.guthr.ie 
 wrote:

 Now, incorporating what you suggest, I guess I have nothing against a
 specific module that actually manipulates a given priority list for you.
 e.g. you could have a module-prefer-usb-for-music module that actually
 implements your desired behaviour in a purely modular fashion by
 automatically rearranging your music priority list for you. Personally I
 think most users would not want it, but for those who do they can load it.


 sorry for jumping in the thread so late, but having worked on
 something similar I think a suitable project already exists. It is the
 resource policy, based on ohm, the git repo is at:

 http://meego.gitorious.org/maemo-multimedia/ohm

 Through this tool it's possible to seamlessly handle whatever we can
 consider a resource (CPU, memory, audio sink/source) depending on the
 system state, which may change after particular events occur (e.g.
 audio jack insertion or removal).

 Many meta-informations like a proper wiki page are missing there
 though, but still it's worth a consideration imho, as the project can
 be considered as already quite stable (let's say it's at production
 level for some targets).

 Thanks for the info.

 I'm actually having a meeting next week to discuss some thing on this
 general topic (loosely speaking) so I'll try and find out a bit more
 about this before then.

 Hmm, interesting:
 http://meego.gitorious.org/maemo-multimedia/ohm/commit/3274a3dca2069865de3ace9a6cef658ee7b521d1

 this project is obsolete and will be replaced with something more
 functional in the near future.

 Wonder what that more interesting project could be!

Actually, the level of interest couldn't be higher than the current
one from my pov :), what the improvements will focus on is the more
functional part. The idea is to keep a similar level of features
(among them automatic audio routing like on the N900) with a smarter
design.

Obviously the project needs wiki page, mailing list and many other
bells and whistles, but nowadays almost everybody's on vacation, so I
guess we'll have to wait at least some weeks for those to arrive.

In the meanwhile, reading this interesting discussion I thought that
before adding complexity to pulseaudio and reinventing the wheel (it's
meant to be a constructive critic), an evaluation about routing audio
from a separate entity should be made, as this approach already works
on existing systems.

Regards,
Marco


 Col

 --

 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/

 Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
 Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

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

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

Re: [pulseaudio-discuss] building PulseAudio from git master

[Colin Guthrie]

'Twas brillig, and Sean McNamara at 16/07/10 00:27 did gyre and gimble:
 Hi Colin,
 
 On Thu, Jul 15, 2010 at 6:57 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Maarten Bosmans at 15/07/10 23:40 did gyre and gimble:
 I'm trying to build PulseAudio from the git master branch. After
 running autogen.sh, the configure script outputs the version as:
 pulseaudio 0.9.19-519-gf26c8.
 Shouldn't this be 0.9.21-*?

 Yeah we should probably bump it right up to 0.9.22 really... I'll do
 that tomorrow.
 
 Does this mean that PA 0.9.22 is due to be released soon? Work has
 continued on PA in git master for a long time since 0.9.21 has been
 released, and a lot of user-facing bugs have been fixed. I noticed
 that Ubuntu (and presumably other distros) are therefore maintaining
 package versions based on git, which seems to suggest the project may
 be moving toward the ffmpeg versioning scheme (i.e., don't release
 stable versions, or if you do, only release them for major milestones
 in the project). Not to say that ffmpeg's stable version policy is
 bad, just that it's a departure from the way PA had been doing things
 up until November of last year. It has been quite a few months since
 PA has rolled an official tarballed release, and some distros have
 policies that discourage or prevent using arbitrary pulls from version
 control if the project is known to make stable releases.


Nothing planned no. Lennart will still be working on systemd for another
month or two and only after he gets back to working on PA full time will
there be any kind of schedule really planned.

 Is the ffmpeg just use git method the way ahead for PA, 

This has been the case for while concerning the stable-queue branch in
git. All the distros ship from this branch as it contains the important
fixes that are not rolled into a release.




Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

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

Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

[Colin Guthrie]

'Twas brillig, and Marco Ballesio at 16/07/10 07:58 did gyre and gimble:
 Hi,
 
 On Thu, Jul 15, 2010 at 5:35 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Colin Guthrie at 08/07/10 10:40 did gyre and gimble:
 'Twas brillig, and Marco Ballesio at 08/07/10 09:37 did gyre and gimble:
 Hi,

 On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie gm...@colin.guthr.ie 
 wrote:

 Now, incorporating what you suggest, I guess I have nothing against a
 specific module that actually manipulates a given priority list for you.
 e.g. you could have a module-prefer-usb-for-music module that actually
 implements your desired behaviour in a purely modular fashion by
 automatically rearranging your music priority list for you. Personally I
 think most users would not want it, but for those who do they can load it.


 sorry for jumping in the thread so late, but having worked on
 something similar I think a suitable project already exists. It is the
 resource policy, based on ohm, the git repo is at:

 http://meego.gitorious.org/maemo-multimedia/ohm

 Through this tool it's possible to seamlessly handle whatever we can
 consider a resource (CPU, memory, audio sink/source) depending on the
 system state, which may change after particular events occur (e.g.
 audio jack insertion or removal).

 Many meta-informations like a proper wiki page are missing there
 though, but still it's worth a consideration imho, as the project can
 be considered as already quite stable (let's say it's at production
 level for some targets).

 Thanks for the info.

 I'm actually having a meeting next week to discuss some thing on this
 general topic (loosely speaking) so I'll try and find out a bit more
 about this before then.

 Hmm, interesting:
 http://meego.gitorious.org/maemo-multimedia/ohm/commit/3274a3dca2069865de3ace9a6cef658ee7b521d1

 this project is obsolete and will be replaced with something more
 functional in the near future.

 Wonder what that more interesting project could be!
 
 Actually, the level of interest couldn't be higher than the current
 one from my pov :), what the improvements will focus on is the more
 functional part. The idea is to keep a similar level of features
 (among them automatic audio routing like on the N900) with a smarter
 design.
 
 Obviously the project needs wiki page, mailing list and many other
 bells and whistles, but nowadays almost everybody's on vacation, so I
 guess we'll have to wait at least some weeks for those to arrive.
 
 In the meanwhile, reading this interesting discussion I thought that
 before adding complexity to pulseaudio and reinventing the wheel (it's
 meant to be a constructive critic), an evaluation about routing audio
 from a separate entity should be made, as this approach already works
 on existing systems.

Well right now there are several projects (outside of my own) going on
in this field, but there does seem to be a little bit of disparity with
upstream people.

One project specifically is coming from the ALSA side and will get
support in PA. This project is very likely to become the defacto method
of operation on embedded systems and thus I would hope that people at
MeeGo would talk more openly about what they are doing so as not to
reinvent the wheel.

I'm not against any kind of external system to deal with client routing
etc. but there is simply not the same level of hooks and controls
available to an external client. There will always be initial routing by
PA then a move from the client. Also, the APIs currently exposed mean
that certain side effects of calling certain API calls (e.g. the
move_sink_input calls) cannot be avoided.

Therefore I really feel that some built in routing management is the way
forward.

Developing a PA module is not hard and I don't really see the benefit of
deveoping several different external systems: one for MeeGo, one for
Gnome, one for KDE etc. etc. I'd rather build it once and let everyone
use it.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

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

Re: [pulseaudio-discuss] building PulseAudio from git master

[Colin Guthrie]

'Twas brillig, and Maarten Bosmans at 15/07/10 23:40 did gyre and gimble:
 Hi,
 
 I'm trying to build PulseAudio from the git master branch. After
 running autogen.sh, the configure script outputs the version as:
 pulseaudio 0.9.19-519-gf26c8.
 Shouldn't this be 0.9.21-*?

Actually, having looked at this (and I should have spotted anyway), the
version is taken directly from git.

As the last tag of the master branch is 0.9.19, it uses that automatically.

If you want a nicer version just do echo 0.9.22  .tarball-version
in the root of your clone and all will be well.

When we release 0.9.22, we will tag it and thus it will automatically
inherit this version.


Personally I prefer a manual way as I feel that as soon as a release is
made the micro version should be incremented so that git master
immediately becomes 0.n.m+1.

This could be incorporated into the script (add one to it) but that's
not wise for building off of a tag...

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

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

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

[Tanu Kaskinen]

On Thu, 2010-07-15 at 21:12 -0500, pl bossart wrote:
 Clean-up of my previous draft, can be applied to git master now.

Thank you for your continued work on this! Here's a review for the
patch.

 +PA_SINK_PASSTHROUGH = 0x0100U
 +/** The latency can be adjusted dynamically depending on the
 + * needs of the connected streams. \since 0.9.22 */
 +

Copy-paste mistake in the documentation.

 +if (dest-flagsPA_SINK_PASSTHROUGH) {

Cosmetic: spaces missing around .

 +for (alt_i = pa_idxset_first(dest-inputs, idx); alt_i; 
 alt_i=pa_idxset_next(dest-inputs, idx)) {

Cosmetic: spaces missing around =.

Also, PA_IDXSET_FOREACH can be used here. Or actually you don't need to
iterate through the set at all, you could just check the first input -
if that's a passthrough input, then it's the only input anyway, and if
it's not a passthrough input, then none of the inputs is a passthrough
input.

 +if (alt_i-flagsPA_SINK_INPUT_PASSTHROUGH) {

Cosmetic: spaces missing around .

 @@ -183,6 +216,8 @@ int pa_sink_input_new(
  pa_return_val_if_fail(PA_SINK_IS_LINKED(pa_sink_get_state(data-sink)), 
 -PA_ERR_BADSTATE);
  
 +
 pa_return_val_if_fail(check_passthrough_connection(data-flags,data-sink), 
 -PA_ERR_INVALID);
 +
  if (!data-sample_spec_is_set)
  data-sample_spec = data-sink-sample_spec;

Cosmetic: space missing between the function arguments.

I wonder if we should return a more descriptive error in case the sink
is used by other streams. Returning just invalid argument doesn't
allow apps to give informative error messages. What do you think?

  void pa_sink_input_set_volume(pa_sink_input *i, const pa_cvolume *volume, 
 pa_bool_t save, pa_bool_t absolute) {
 +
 +/* Do not allow for volume changes for non-audio types */
 +if (i-flags  PA_SINK_INPUT_PASSTHROUGH)
 +return;
 +

Cosmetic: bad indentation of the comment. (I guess this will be replaced
anyway when the volume handling is done properly, but it doesn't hurt to
have good formatting on temporary code too...)

 +if(!check_passthrough_connection(i-flags,dest))

Cosmetic: space missing between the function arguments.

 +if (s-flagsPA_SINK_PASSTHROUGH) {

Cosmetic: spaces missing around .

 +if (alt_i-flagsPA_SINK_INPUT_PASSTHROUGH) {

Cosmetic: spaces missing around .

Regarding volume handling, I think there should be

pa_assert(!((data-flags  PA_SINK_INPUT_PASSTHROUGH)  
data-volume_is_set));

somewhere in pa_sink_input_new, and checks in protocol-native.c to
prevent that assertion from firing. That is, refuse to create
passthrough streams that also have volume specified by the client.

-- 
Tanu Kaskinen

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

Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

[Jan Braun]

Colin Guthrie schrob:
 'Twas brillig, and Jan Braun at 15/07/10 06:07 did gyre and gimble:
  1. Shouldn't PA do only obvious things automatically, and not bug the
 user about obvious things? The proposition PA automaticallly breaks
 stuff, so it needs to show the user how to unbreak it seems flawed.
 
 Depends on your definition. I'm a firm believer of doing the right thing
 automatically and if you can't work out what the right thing is, then
 don't do it at all. But when it does do something automatically, I'd
 quite like to be informed about it. This already happens on KDE with
 their Phonon system, so it's not unprecedented, but all the same it may
 not be liked by Gnomey folk. But hey, it will be optional.

Ok, sonds reasonable.
(Except for the assertion PA users = KDE xor Gnome. Grr. :)

  2. Isn't PA a daemon and thus can't interact with the user? Or did you
 mean set a flag that pavucontrol etc. can read? But then the user
 still would have to run pavucontrol on their own...
 [...]
 It would be pretty trivial to load a notification module in the
 start-pulseaudio-x11 script and this was my intention.

True, thanks.

  If you can't tell, I'm concerned about PA not staying out of my way.
 
 It'll be a module, so it will be optional.

Yep. And being conditional on start-pulseaudio-x11 makes it stay out of
my way automatically. Thanks! :D

Jan
-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


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

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

[pl bossart]

 +    PA_SINK_PASSTHROUGH = 0x0100U
 +    /** The latency can be adjusted dynamically depending on the
 +     * needs of the connected streams. \since 0.9.22 */
 +

 Copy-paste mistake in the documentation.

No this was done on purpose. We are already at 0.9.21 so the next
version is logically 0.9.22?

 Also, PA_IDXSET_FOREACH can be used here. Or actually you don't need to
 iterate through the set at all, you could just check the first input -
 if that's a passthrough input, then it's the only input anyway, and if
 it's not a passthrough input, then none of the inputs is a passthrough
 input.

Yes. I wrote some code but somehow I dropped it. Will fix it.

 I wonder if we should return a more descriptive error in case the sink
 is used by other streams. Returning just invalid argument doesn't
 allow apps to give informative error messages. What do you think?

Maybe adding an error code for passthrough connections would do.
INVALID is too vague I guess?

 somewhere in pa_sink_input_new, and checks in protocol-native.c to
 prevent that assertion from firing. That is, refuse to create
 passthrough streams that also have volume specified by the client.

I think it's better to ignore volume settings rather than refuse the connection?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

[pl bossart]

 Well right now there are several projects (outside of my own) going on
 in this field, but there does seem to be a little bit of disparity with
 upstream people.

 One project specifically is coming from the ALSA side and will get
 support in PA. This project is very likely to become the defacto method
 of operation on embedded systems and thus I would hope that people at
 MeeGo would talk more openly about what they are doing so as not to
 reinvent the wheel.

If you are talking about the audio scenarios developed by Liam, I
don't think there's any sort of conflict. it's my understanding that
the scenarios are mainly to configure the hardware routing and
performance of a given audio device using specific settings (eg voice
volume, etc).
This thread is more about what output will be used if you have
multiple audio accessories or peripherals. It's one level higher I
guess.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

[Tanu Kaskinen]

On Fri, 2010-07-16 at 11:31 -0500, pl bossart wrote:
  +PA_SINK_PASSTHROUGH = 0x0100U
  +/** The latency can be adjusted dynamically depending on the
  + * needs of the connected streams. \since 0.9.22 */
  +
 
  Copy-paste mistake in the documentation.
 
 No this was done on purpose. We are already at 0.9.21 so the next
 version is logically 0.9.22?

I mean the actual content. It's copied from PA_SINK_DYNAMIC_LATENCY.

  Also, PA_IDXSET_FOREACH can be used here. Or actually you don't need to
  iterate through the set at all, you could just check the first input -
  if that's a passthrough input, then it's the only input anyway, and if
  it's not a passthrough input, then none of the inputs is a passthrough
  input.
 
 Yes. I wrote some code but somehow I dropped it. Will fix it.
 
  I wonder if we should return a more descriptive error in case the sink
  is used by other streams. Returning just invalid argument doesn't
  allow apps to give informative error messages. What do you think?
 
 Maybe adding an error code for passthrough connections would do.
 INVALID is too vague I guess?

PA_ERR_BUSY seems to exist already. I think it could be used here.

  somewhere in pa_sink_input_new, and checks in protocol-native.c to
  prevent that assertion from firing. That is, refuse to create
  passthrough streams that also have volume specified by the client.
 
 I think it's better to ignore volume settings rather than refuse the 
 connection?

If an application creates a passthrough stream, it should know that
setting the volume doesn't make sense. Making the stream creation fail
makes it obvious to the application writer that his code is broken.
(It's probably quite unlikely that any application would do that in the
first place, but that's beside the point.)

Anyway, currently the patch doesn't ignore the initial stream volume, so
if it's set, then the audio probably becomes corrupted.

-- 
Tanu Kaskinen

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

Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

[Mark Brown]

On Fri, Jul 16, 2010 at 11:41:33AM -0500, pl bossart wrote:
  Well right now there are several projects (outside of my own) going on
  in this field, but there does seem to be a little bit of disparity with
  upstream people.

  One project specifically is coming from the ALSA side and will get
  support in PA. This project is very likely to become the defacto method
  of operation on embedded systems and thus I would hope that people at
  MeeGo would talk more openly about what they are doing so as not to
  reinvent the wheel.

 If you are talking about the audio scenarios developed by Liam, I
 don't think there's any sort of conflict. it's my understanding that
 the scenarios are mainly to configure the hardware routing and
 performance of a given audio device using specific settings (eg voice
 volume, etc).
 This thread is more about what output will be used if you have
 multiple audio accessories or peripherals. It's one level higher I
 guess.

I missed the start of this discussion so I'm missing some context here
but there may actually quite a bit of overlap here - on systems like
smartphones it's very common for all the audio to be a single integrated
subsystem with multiple paths through it and the CPU as only one node in
that system.  Things like Bluetooth headsets wouldn't appear as a
separate sound card, they'd appear as an output option on the existing
sound card, and many audio paths will be connected directly through the
hardware without entering the PulseAudio domain.

Since there can be multiple paths through the system you can also end up
with different streams on the CPU being routed separately - the classic
example is having an MP3 playing to headphones and simultaneously
ringtone/alert sounds routed to both headphones and speaker.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support

[pl bossart]

Second version to address Tanu's feedback. Should be good enough by
now for actual use.


0001-AC3-passthrough-support.patch
Description: Binary data
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss