Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense

[Mark Brown]

On Tue, Apr 12, 2011 at 02:14:04PM -0500, pl bossart wrote:
> > Jack detect does not use the ALSA kernel subsystem but does instead
> > use the input subsystem for jack status. It makes sense to create a
> > new module so we can then use jack detect for non ALSA sound devices.

> I'm a bit lost here. What are 'non ALSA sound devices'?
> And to the best of my knowledge these events are only generated by
> ALSA drivers...
> Am I missing something here?

These events can be generated by anything - prior to my implementing the
ALSA support for this all the implementations in mainline were doing
this via the gpio-keys driver since they were detecting a microswitch in
the jack.  I'd expect that non-audio jacks may also end up reporting via
the same interface (video for example), but I'm not sure if Pulse would
be interested in anything non-ALSA.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] rygel mediaserver

[Gunnar Aastrand Grimnes]

I think you have to load module-protocol-http as well (not sure I've got
the name totally correct).


That's the one I meant when I said "I have also enabled the http-tcp 
module," - it's called module-http-protocol-tcp




I tried it with my PS3 but never got very far (it defo did try to talk
to the http module tho')

If you get it working with your WDTV box just by loading http protocol,
please report back and I'll tweak paprefs.


No such luck. Running pa in a console it says:


I: socket-server.c: TCP connection accepted by tcpwrap.
I: client.c: Created 12 "HTTP client (TCP/IP client from 
192.168.178.99:41994)"
I: client.c: Freed 12 "HTTP client (TCP/IP client from 
192.168.178.99:41994)"


immediately, and the WDTV says "unable to play the selected file".

With my LG HB405SU there is on such message, but rygel says:

** (rygel:10171): WARNING **: rygel-http-request.vala:91: Invalid seek 
request


When I try to play the stream.

Cheers,

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

Re: [pulseaudio-discuss] pulseaudio

[Colin Guthrie]

'Twas brillig, and duportail at 12/04/11 19:20 did gyre and gimble:
> Op 12-4-2011 18:53, Tanu Kaskinen schreef:
>> On Tue, 2011-04-12 at 12:30 -0400, Sean McNamara wrote:
>>> Hi,
>>>
>>> On Tue, Apr 12, 2011 at 12:15 PM, duportail  wrote:
 Try to test the new xubuntu 11.04 with kde on a multi-user system.
 The first user (for example user1) can log in and gets a default
 sink from
 pulse.
 The second user(for example user2) that will log in gets a auto_null
 because
 pulse did not found any sinks.
 If i log out user1, than user2 can get a default sink by kill and start
 pulse.
 Where should be the reason?
>>> This is the "classic" multi-user problem: you're using a soundcard
>>> without hardware mixing, so only one ALSA application can take direct
>>> control of the hardware device at a time. user1's pulseaudio daemon
>>> takes control of it, so obviously user2's PA daemon will just get
>>> "Device or resource busy" when trying to snd_pcm_open() on hw:0 (for
>>> example). This problem has existed since ALSA existed. There's no
>>> direct fix without scrapping the API and rewriting it.
>> Actually, this situation is supposed to be handled just fine (unless
>> duportail expects both users to be able to use the audio hw
>> simultaneously, which he doesn't mention). If this doesn't work, xubuntu
>> is broken. Some things that can cause this problem: the users are in the
>> "audio" group, consolekit isn't running or consolekit's udev-acl isn't
>> in use.
>>
> Maybe xubuntu is broken.I will wait until further releases

Make sure that ck-list-sessions reports correctly that only the active
user is actually active.

Also check the user groups as Tanu reported.

But all in all, this *should* be handled correctly (and certainly is on
other systems)


Col

-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

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

Re: [pulseaudio-discuss] [RFC] Pulseaudio jack sense

[pl bossart]

> Jack detect does not use the ALSA kernel subsystem but does instead
> use the input subsystem for jack status. It makes sense to create a
> new module so we can then use jack detect for non ALSA sound devices.

I'm a bit lost here. What are 'non ALSA sound devices'?
And to the best of my knowledge these events are only generated by
ALSA drivers...
Am I missing something here?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio

[duportail]

Op 12-4-2011 18:53, Tanu Kaskinen schreef:

On Tue, 2011-04-12 at 12:30 -0400, Sean McNamara wrote:

Hi,

On Tue, Apr 12, 2011 at 12:15 PM, duportail  wrote:

Try to test the new xubuntu 11.04 with kde on a multi-user system.
The first user (for example user1) can log in and gets a default sink from
pulse.
The second user(for example user2) that will log in gets a auto_null because
pulse did not found any sinks.
If i log out user1, than user2 can get a default sink by kill and start
pulse.
Where should be the reason?

This is the "classic" multi-user problem: you're using a soundcard
without hardware mixing, so only one ALSA application can take direct
control of the hardware device at a time. user1's pulseaudio daemon
takes control of it, so obviously user2's PA daemon will just get
"Device or resource busy" when trying to snd_pcm_open() on hw:0 (for
example). This problem has existed since ALSA existed. There's no
direct fix without scrapping the API and rewriting it.

Actually, this situation is supposed to be handled just fine (unless
duportail expects both users to be able to use the audio hw
simultaneously, which he doesn't mention). If this doesn't work, xubuntu
is broken. Some things that can cause this problem: the users are in the
"audio" group, consolekit isn't running or consolekit's udev-acl isn't
in use.


Maybe xubuntu is broken.I will wait until further releases

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

Re: [pulseaudio-discuss] crackle and stutter

[Brian J. Murrell]

On 11-04-12 12:52 PM, Sean McNamara wrote:
> 
> I can't tell from your PA logs which soundcard you are using to play
> back notifications and rhythmbox sound?
> 
>  0 [NVidia ]: HDA-Intel - HDA NVidia
>   HDA NVidia at 0xfe024000 irq 22

Yes, this one.

> or
> 
>  1 [U0x46d0x8c5]: USB-Audio - USB Device 0x46d:0x8c5
>   USB Device 0x46d:0x8c5 at usb-:00:0b.1-3, high speed

This is a webcam with only a mic on it.

> [   14.160524] hda_intel: Disable MSI for Nvidia chipset
> ...
> [691084.544026] hda_codec: invalid CONNECT_LIST verb 12[2]:2100
> [691120.324230] hda_codec: invalid CONNECT_LIST verb 12[2]:2100
> [691203.712806] hda_codec: invalid CONNECT_LIST verb 12[2]:2100
> [691277.537037] hda_codec: invalid CONNECT_LIST verb 12[2]:2100

Last one was there was at Apr 12 12:17:46.

> Hmm. Can you correlate "PulseAudio is dropping out" with one of these
> messages? 691277 seconds after startup would be 8 days and some
> minutes after kernel init, so it seems recent?

There is no correlation unfortunately.  I just had a dropout and no new
messages of that nature.

b.



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

Re: [pulseaudio-discuss] pulseaudio

[Tanu Kaskinen]

On Tue, 2011-04-12 at 12:30 -0400, Sean McNamara wrote:
> Hi,
> 
> On Tue, Apr 12, 2011 at 12:15 PM, duportail  wrote:
> > Try to test the new xubuntu 11.04 with kde on a multi-user system.
> > The first user (for example user1) can log in and gets a default sink from
> > pulse.
> > The second user(for example user2) that will log in gets a auto_null because
> > pulse did not found any sinks.
> > If i log out user1, than user2 can get a default sink by kill and start
> > pulse.
> > Where should be the reason?
> 
> This is the "classic" multi-user problem: you're using a soundcard
> without hardware mixing, so only one ALSA application can take direct
> control of the hardware device at a time. user1's pulseaudio daemon
> takes control of it, so obviously user2's PA daemon will just get
> "Device or resource busy" when trying to snd_pcm_open() on hw:0 (for
> example). This problem has existed since ALSA existed. There's no
> direct fix without scrapping the API and rewriting it.

Actually, this situation is supposed to be handled just fine (unless
duportail expects both users to be able to use the audio hw
simultaneously, which he doesn't mention). If this doesn't work, xubuntu
is broken. Some things that can cause this problem: the users are in the
"audio" group, consolekit isn't running or consolekit's udev-acl isn't
in use.

-- 
Tanu

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

Re: [pulseaudio-discuss] crackle and stutter

[Sean McNamara]

On Tue, Apr 12, 2011 at 12:24 PM, Brian J. Murrell
 wrote:
> On 11-04-12 12:00 PM, Sean McNamara wrote:
>> Hi,
>
> Hi,
>
>> Can you give an example of what application(s) in particular trigger
>> this?
>
> Skype for example, when somebody sends an IM, or logs on.  Skype pops up
> a notification and emits a sound event.  Or when I generate a keyboard
> sound event, like hitting tab a bunch of times at a bash prompt.  It
> displays:
>
> Display all 5014 possibilities? (y or n)
>
> For example, and each tab emits a sound event.  If I hit tab a good
> number of times I can see this in PA:
>
> D: core-scache.c: Playing sample "bell-window-system" on
> "alsa_output.pci-_00_10.1.analog-stereo"
> D: memblockq.c: memblockq requested: maxlength=17640, tlength=0, base=2,
> prebuf=1, minreq=1 maxrewind=0
> D: memblockq.c: memblockq sanitized: maxlength=17640, tlength=17640,
> base=2, prebuf=2, minreq=2 maxrewind=0
> D: module-stream-restore.c: Not restoring device for stream
> sink-input-by-media-role:event, because already set to
> 'alsa_output.pci-_00_10.1.analog-stereo'.
> D: module-intended-roles.c: Not setting device for stream
> bell-window-system, because already set.
> I: module-stream-restore.c: Restoring volume for sink input
> sink-input-by-media-role:event.
> I: module-stream-restore.c: Restoring mute state for sink input
> sink-input-by-media-role:event.
> D: module-suspend-on-idle.c: Sink
> alsa_output.pci-_00_10.1.analog-stereo becomes busy.
> I: resampler.c: Forcing resampler 'copy', because of fixed, identical
> sample rates.
> D: resampler.c: Channel matrix:
> D: resampler.c:        I00
> D: resampler.c:     +--
> D: resampler.c: O00 | 1.000
> D: resampler.c: O01 | 1.000
> I: remap_sse.c: Using SSE mono to stereo remapping
> I: resampler.c: Using resampler 'copy'
> I: resampler.c: Using s16le as working format.
> D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0,
> base=4, prebuf=0, minreq=1 maxrewind=0
> D: memblockq.c: memblockq sanitized: maxlength=33554432,
> tlength=33554432, base=4, prebuf=0, minreq=4 maxrewind=0
> I: sink-input.c: Created input 6004 "bell-window-system" on
> alsa_output.pci-_00_10.1.analog-stereo with sample spec s16le 1ch
> 44100Hz and channel map mono
> I: sink-input.c:     media.name = "bell-window-system"
> I: sink-input.c:     event.id = "bell-window-system"
> I: sink-input.c:     media.role = "event"
> I: sink-input.c:     application.process.id = "3904"
> I: sink-input.c:     application.name = "gnome-terminal"
> I: sink-input.c:     event.description = "Bell event"
> I: sink-input.c:     media.filename =
> "/usr/share//sounds/ubuntu/stereo/bell.ogg"
> I: sink-input.c:     native-protocol.peer = "UNIX socket client"
> I: sink-input.c:     native-protocol.version = "16"
> I: sink-input.c:     window.x11.display = ":0.0"
> I: sink-input.c:     window.x11.screen = "0"
> I: sink-input.c:     application.process.user = "brian"
> I: sink-input.c:     application.process.host = "pc"
> I: sink-input.c:     application.process.binary = "metacity"
> I: sink-input.c:     application.language = "en_CA.UTF-8"
> I: sink-input.c:     application.process.machine_id =
> "c5af5645621daea8981bd8ac95e82500"
> I: sink-input.c:     application.process.session_id =
> "c5af5645621daea8981bd8ac95e82500-1301933908.840922-406521422"
> I: sink-input.c:     window.x11.xid = "48333716"
> I: sink-input.c:     window.name = "pc:/etc/shorewall6/gw-new"
> I: sink-input.c:     module-stream-restore.id =
> "sink-input-by-media-role:event"
> D: core-util.c: posix_madvise() worked fine!
> D: alsa-sink.c: Requested to rewind 352768 bytes.
> D: alsa-sink.c: Limited to 21016 bytes.
> D: alsa-sink.c: before: 5254
> D: alsa-sink.c: after: 5254
> D: alsa-sink.c: Rewound 21016 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
> D: source.c: Processing rewind...
> D: als

Re: [pulseaudio-discuss] pulseaudio

[duportail]

Op 12-4-2011 18:30, Sean McNamara schreef:

Hi,

On Tue, Apr 12, 2011 at 12:15 PM, duportail  wrote:

Try to test the new xubuntu 11.04 with kde on a multi-user system.
The first user (for example user1) can log in and gets a default sink from
pulse.
The second user(for example user2) that will log in gets a auto_null because
pulse did not found any sinks.
If i log out user1, than user2 can get a default sink by kill and start
pulse.
Where should be the reason?

This is the "classic" multi-user problem: you're using a soundcard
without hardware mixing, so only one ALSA application can take direct
control of the hardware device at a time. user1's pulseaudio daemon
takes control of it, so obviously user2's PA daemon will just get
"Device or resource busy" when trying to snd_pcm_open() on hw:0 (for
example). This problem has existed since ALSA existed. There's no
direct fix without scrapping the API and rewriting it.

I guess there is no solution yet (still) in 11.04, but you can see
that folks in the Ubuntu community are trying to resolve the issue
with a number of possible approaches:
https://wiki.edubuntu.org/BluePrints/multiuser-soundcards-pulseaudio

Running as system-wide is one possible approach...
http://www.pulseaudio.org/wiki/SystemWideInstance

Not sure if there's yet a solution allowing the use of shm and
module-native-protocol-unix for multiple users (this is ideally what
you'd want for maximum performance / minimum latency), but it's quite
easy to set up module-native-protocol-tcp and connect to localhost
using the `default-server' parameter in client.conf, at the cost of
latency. Let me know if you need more details on this particular
approach.

BTW, search the archives of this list at gmane<
http://blog.gmane.org/gmane.comp.audio.pulseaudio.general>  -- there
are many many historical posts about multi-user setups.



Sean


gd

___
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

Sorry, forgot to mention: there multiple (two) usb soundcards on the 
system.It is working good on xubuntu 10.10.
As you said, the second user gets a "Device or resource busy".When I 
logout the first user, the second user can get a default sink.

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

Re: [pulseaudio-discuss] pulseaudio

[Sean McNamara]

Hi,

On Tue, Apr 12, 2011 at 12:15 PM, duportail  wrote:
> Try to test the new xubuntu 11.04 with kde on a multi-user system.
> The first user (for example user1) can log in and gets a default sink from
> pulse.
> The second user(for example user2) that will log in gets a auto_null because
> pulse did not found any sinks.
> If i log out user1, than user2 can get a default sink by kill and start
> pulse.
> Where should be the reason?

This is the "classic" multi-user problem: you're using a soundcard
without hardware mixing, so only one ALSA application can take direct
control of the hardware device at a time. user1's pulseaudio daemon
takes control of it, so obviously user2's PA daemon will just get
"Device or resource busy" when trying to snd_pcm_open() on hw:0 (for
example). This problem has existed since ALSA existed. There's no
direct fix without scrapping the API and rewriting it.

I guess there is no solution yet (still) in 11.04, but you can see
that folks in the Ubuntu community are trying to resolve the issue
with a number of possible approaches:
https://wiki.edubuntu.org/BluePrints/multiuser-soundcards-pulseaudio

Running as system-wide is one possible approach...
http://www.pulseaudio.org/wiki/SystemWideInstance

Not sure if there's yet a solution allowing the use of shm and
module-native-protocol-unix for multiple users (this is ideally what
you'd want for maximum performance / minimum latency), but it's quite
easy to set up module-native-protocol-tcp and connect to localhost
using the `default-server' parameter in client.conf, at the cost of
latency. Let me know if you need more details on this particular
approach.

BTW, search the archives of this list at gmane <
http://blog.gmane.org/gmane.comp.audio.pulseaudio.general > -- there
are many many historical posts about multi-user setups.



Sean

>
> gd
>
> ___
> 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] crackle and stutter

[Brian J. Murrell]

On 11-04-12 12:00 PM, Sean McNamara wrote:
> Hi,

Hi,

> Can you give an example of what application(s) in particular trigger
> this?

Skype for example, when somebody sends an IM, or logs on.  Skype pops up
a notification and emits a sound event.  Or when I generate a keyboard
sound event, like hitting tab a bunch of times at a bash prompt.  It
displays:

Display all 5014 possibilities? (y or n)

For example, and each tab emits a sound event.  If I hit tab a good
number of times I can see this in PA:

D: core-scache.c: Playing sample "bell-window-system" on
"alsa_output.pci-_00_10.1.analog-stereo"
D: memblockq.c: memblockq requested: maxlength=17640, tlength=0, base=2,
prebuf=1, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=17640, tlength=17640,
base=2, prebuf=2, minreq=2 maxrewind=0
D: module-stream-restore.c: Not restoring device for stream
sink-input-by-media-role:event, because already set to
'alsa_output.pci-_00_10.1.analog-stereo'.
D: module-intended-roles.c: Not setting device for stream
bell-window-system, because already set.
I: module-stream-restore.c: Restoring volume for sink input
sink-input-by-media-role:event.
I: module-stream-restore.c: Restoring mute state for sink input
sink-input-by-media-role:event.
D: module-suspend-on-idle.c: Sink
alsa_output.pci-_00_10.1.analog-stereo becomes busy.
I: resampler.c: Forcing resampler 'copy', because of fixed, identical
sample rates.
D: resampler.c: Channel matrix:
D: resampler.c:I00
D: resampler.c: +--
D: resampler.c: O00 | 1.000
D: resampler.c: O01 | 1.000
I: remap_sse.c: Using SSE mono to stereo remapping
I: resampler.c: Using resampler 'copy'
I: resampler.c: Using s16le as working format.
D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0,
base=4, prebuf=0, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=33554432,
tlength=33554432, base=4, prebuf=0, minreq=4 maxrewind=0
I: sink-input.c: Created input 6004 "bell-window-system" on
alsa_output.pci-_00_10.1.analog-stereo with sample spec s16le 1ch
44100Hz and channel map mono
I: sink-input.c: media.name = "bell-window-system"
I: sink-input.c: event.id = "bell-window-system"
I: sink-input.c: media.role = "event"
I: sink-input.c: application.process.id = "3904"
I: sink-input.c: application.name = "gnome-terminal"
I: sink-input.c: event.description = "Bell event"
I: sink-input.c: media.filename =
"/usr/share//sounds/ubuntu/stereo/bell.ogg"
I: sink-input.c: native-protocol.peer = "UNIX socket client"
I: sink-input.c: native-protocol.version = "16"
I: sink-input.c: window.x11.display = ":0.0"
I: sink-input.c: window.x11.screen = "0"
I: sink-input.c: application.process.user = "brian"
I: sink-input.c: application.process.host = "pc"
I: sink-input.c: application.process.binary = "metacity"
I: sink-input.c: application.language = "en_CA.UTF-8"
I: sink-input.c: application.process.machine_id =
"c5af5645621daea8981bd8ac95e82500"
I: sink-input.c: application.process.session_id =
"c5af5645621daea8981bd8ac95e82500-1301933908.840922-406521422"
I: sink-input.c: window.x11.xid = "48333716"
I: sink-input.c: window.name = "pc:/etc/shorewall6/gw-new"
I: sink-input.c: module-stream-restore.id =
"sink-input-by-media-role:event"
D: core-util.c: posix_madvise() worked fine!
D: alsa-sink.c: Requested to rewind 352768 bytes.
D: alsa-sink.c: Limited to 21016 bytes.
D: alsa-sink.c: before: 5254
D: alsa-sink.c: after: 5254
D: alsa-sink.c: Rewound 21016 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: sink-input.c: Have to rewind 21016 bytes on render memblockq.
D: source.c: Processing rewind...
D: alsa-sink.c: Latency set to 136.00ms
D: alsa-sink.c: hwbuf_unused=328780
D: alsa-sink.c: setting avail_min=83952
D: alsa-sink.c: Requested to rewind 352768 bytes.
D: alsa-sink.c: Limited to 23660 bytes.
D: alsa-sink.c: before: 5915
D: alsa-sink.c: after: 59

[pulseaudio-discuss] pulseaudio

[duportail]

Try to test the new xubuntu 11.04 with kde on a multi-user system.
The first user (for example user1) can log in and gets a default sink 
from pulse.
The second user(for example user2) that will log in gets a auto_null 
because pulse did not found any sinks.
If i log out user1, than user2 can get a default sink by kill and start 
pulse.

Where should be the reason?

gd

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

Re: [pulseaudio-discuss] crackle and stutter

[Sean McNamara]

Hi,

On Tue, Apr 12, 2011 at 11:14 AM, Brian J. Murrell
 wrote:
> It seems inevitable that my pulse audio server
> (0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 on Ubuntu Maverick)
> will start sounding crackly and stuttery when an application wants to
> send "notification" type sounds.

Can you give an example of what application(s) in particular trigger
this? Is it reproducible 100% of the time, or just sometimes? How is
your CPU load when this is occurring?

>
> When this happens, about the only useful thing I see in the "-vvv"
> output is:
>
> D: alsa-sink.c: Requested to rewind 22988 bytes.
> D: alsa-sink.c: Limited to 22988 bytes.
> D: alsa-sink.c: before: 5747
> D: alsa-sink.c: after: 5747
> D: alsa-sink.c: Rewound 22988 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 22988 bytes on render memblockq.
> D: sink-input.c: Have to rewind 22988 bytes on render memblockq.
> D: sink-input.c: Have to rewind 11496 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 23120 bytes.
> D: alsa-sink.c: Limited to 23120 bytes.
> D: alsa-sink.c: before: 5780
> D: alsa-sink.c: after: 5780
> D: alsa-sink.c: Rewound 23120 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 23120 bytes on render memblockq.
> D: sink-input.c: Have to rewind 23120 bytes on render memblockq.
> D: sink-input.c: Have to rewind 11560 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 21480 bytes.
> D: alsa-sink.c: Limited to 21480 bytes.
> D: alsa-sink.c: before: 5370
> D: alsa-sink.c: after: 5370
> D: alsa-sink.c: Rewound 21480 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 21480 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21480 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10740 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 21848 bytes.
> D: alsa-sink.c: Limited to 21848 bytes.
> D: alsa-sink.c: before: 5462
> D: alsa-sink.c: after: 5462
> D: alsa-sink.c: Rewound 21848 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 21848 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21848 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10924 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 20212 bytes.
> D: alsa-sink.c: Limited to 20212 bytes.
> D: alsa-sink.c: before: 5053
> D: alsa-sink.c: after: 5053
> D: alsa-sink.c: Rewound 20212 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 20212 bytes on render memblockq.
> D: sink-input.c: Have to rewind 20212 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10108 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 20336 bytes.
> D: alsa-sink.c: Limited to 20336 bytes.
> D: alsa-sink.c: before: 5084
> D: alsa-sink.c: after: 5084
> D: alsa-sink.c: Rewound 20336 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 20336 bytes on render memblockq.
> D: sink-input.c: Have to rewind 20336 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10168 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 19012 bytes.
> D: alsa-sink.c: Limited to 19012 bytes.
> D: alsa-sink.c: before: 4753
> D: alsa-sink.c: after: 4753
> D: alsa-sink.c: Rewound 19012 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 19012 bytes on render memblockq.
> D: sink-input.c: Have to rewind 19012 bytes on render memblockq.
> D: sink-input.c: Have to rewind 9508 bytes on implementor.
>
> I'm not really sure what this is telling me though.  Is the above
> normal?  Is there something else I should be looking for?

Some amount of rewinds are normal. Especially when the server first
starts up, or when the amount of latency demanded by an application is
very low while system load is high. But excessive rewinds can be due
to a driver bug in ALSA (this would have to be specific to your
hardware since I can't reproduce the issue here on Maverick). I like
to compare it to an anti-lock break system: if it engages at the right
time, it's useful, but if it engages erroneously it can be dangerous.

If you're getting lots of rewinds while the server is underway with a
relatively low CP

Re: [pulseaudio-discuss] Weird bug with Pulseaudio connections.

[Sean McNamara]

Hi,

On Tue, Apr 12, 2011 at 11:08 AM, Robbie Smith  wrote:
> Hello everyone
>
> I haven't posted to this list before, not being much of a developer, but
> I've been having some really odd bugs pop up almost at random with
> Pulseaudio. Usually they disappear days or weeks later with just as much
> warning as when they occur, and I'm never sure whether I've solved them
> or whether my computer is just ... odd.
>
> Anyway, the main nature of the bugs is that Pulseaudio seems to have
> difficulty connecting to either ALSA, my sound card, or something else.
> I can't quite explain what's going on; I've tried reading
> through /var/log/errors.log and noticed that it is "failing to set
> hardware parameters with a connection timeout". I'm not quite familiar
> with how Pulseaudio works, but from the odd arcane messages I get, I'm
> guessing that somewhere, somehow, it's trying to talk to my soundcard
> and my soundcard is responding with "Computer says no."
>
> The weird bit is that the "bug", if that's what it is, gets triggered by
> almost anything. Commonly, opening pavucontrol will kill sound for a few
> seconds to a few minutes: sound only resumes once I've killed
> pavucontrol, and a dialog/error box will pop up alerting me to a
> connection timeout. Given that pavucontrol is a really useful way of
> manipulating the volume of individual programs this can be quite
> annoying.
>
> Before I describe what methods I've attempted to solve the problems,
> I'll just briefly list my OS. I'm currently running Arch Linux, with (as
> of tonight) the latest (stable) kernel 2.6.38.2 according to my update
> logs. Pulseaudio itself is version 0.9.22. My desktop "environment" is
> Openbox, and I'm calling it within consolekit and polkit and whatever
> else it needs.
>
>        The command being called from ~/.xinitrc is
>        exec /usr/bin/ck-launch-session /usr/bin/openbox-session
>
>        start-pulseaudio-x11 is also being called in this file, a few
>        lines up.
>
>
> As for setting up my system, I think I've tried just about every guide
> there is, and there's a lot of conflicting information out there,
> especially on user and group permissions. Sometimes following a guide
> for the sake of it fixes the bug; that being said, I've already had the
> settings it recommends so I have no idea what's going on.
>
> I've experimented with setting sinks, with setting sound outputs,
> everything. But time and again this weird bug shows up, pulseaudio fails
> to load, or the pavucontrol applet brings the sound to a halt, or
> something. And without warning it'll start working again, usually within
> hours of me asking on a forum somewhere about the bug.
>
> As far as I know I've installed everything that might be needed. I used
> to like Pulseaudio, the whole control-volume-of-individual-streams is
> great. But it just doesn't work (between some of the time to most of the
> time). And yet it's one of those features, which once you get used to
> it, is really hard to live without.
>
> How can I fix this once and for all? If there's any configuration
> details or similar that you might need to be able to confirm or identify
> the bug or whatever conditions are causing this, let me know what you
> need to know and I'll try to assist in any way I can.

Posting your output of alsa-info.sh <
http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=utils/alsa-info.sh
> would be good for starters.

Also, a bit of an intuitive guess, but maybe when pulseaudio releases
the soundcard (you have module-suspend-on-idle loaded, right?) another
app is coming in and hogging the soundcard meanwhile. Since you
haven't posted anything from pulseaudio logs, I can't be sure if this
is the problem, though.

If indeed something is taking the ALSA sound device while pulseaudio
relinquishes it, you could try disabling module-suspend-on-idle in
/etc/pulse/default.pa. Just comment out the load-module line for it.
If it doesn't fix your issue, re-enable the module because it saves
power (especially relevant on a laptop).

Last stab in the dark (I think I've made enough of them in this post
already): Arch Linux is not known for being well-tested and
integrating packages into the distro. The problems you're experiencing
may be an artifact of "following guides" out there on the internet,
without really knowing what the guides are guiding you to do (and
sometimes/often the guides are incorrect or obsolete). For that
matter, you should take *my* advice with a grain of salt, too. But if
you want something that just works, kick the tires on the latest
stable of one of the premiere distros (Ubuntu, Fedora, OpenSUSE) and
see if you can reproduce the problem. If not, the error is most likely
something you did (or something ArchLinux fails to do), or a distro
patch has been included in the kernel, ALSA, or pulseaudio that fixes
your issue but your distro hasn't picked it up.

You won't be able to fix your issue "once and for all" unless you can
isolat

Re: [pulseaudio-discuss] rygel mediaserver

[Colin Guthrie]

'Twas brillig, and Gunnar Aastrand Grimnes at 11/04/11 11:27 did gyre
and gimble:
> Hi all,
> 
> What is the status of the rygel mediaserver integration atm?
> 
> In paprefs I can enable upnp/dnla sharing, and the services and stream
> appears in any players on my network, however, actually playing the
> stream does not work. I have tried with my WDTV box, a LG BlueRay+DLVA
> player and simply playing the stream locally with the upnp-inspector.
> 
> I have also enabled the http-tcp module, as someone said this was needed.
> 
> The rygel webpage says something about MediaServer spec v1 being
> deprecated, and that pulse needs to implement v2, but this appears to be
> done here:
> 
> http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/module-rygel-media-server.c;hb=ff7acb4d059e21b318b0464ee6fd1785318071cc
> 
> 
> Does anyone have this working?
> Any hints for debugging what goes wrong?

I think you have to load module-protocol-http as well (not sure I've got
the name totally correct).

I tried it with my PS3 but never got very far (it defo did try to talk
to the http module tho')

If you get it working with your WDTV box just by loading http protocol,
please report back and I'll tweak paprefs.

Col



-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

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

Re: [pulseaudio-discuss] keys for raop server

[Colin Guthrie]

'Twas brillig, and Daniel Mack at 11/04/11 14:28 did gyre and gimble:
> 2011/4/11 Rémi Denis-Courmont :
>> On Mon, 11 Apr 2011 12:39:38 +0200, Tomasz Torcz 
>> wrote:
>>>  Some interested in adding server functionality to PA,
>>> using attached key?
>>
>> On a side note, I understood (from an Apple AirPort engineer) that there
>> is no need to do the cryptographic stuff to SEND to an ApEx. If it's true,
>> then many hoops in PulseAudio and VLC's RAOP outputs are nasically
>> redumdant.
>>
>> Of course, for an RAOP input, you do need the cryptography (if the remote
>> client asks). I'm not sure how well this fits into PulseAudio though? It
>> does not have a decoder for Apple Lossless, does it?
> 
> That's true. Streaming from another Mac would also only be interesting
> for iTunes, as all other applications are not (natively) able to
> stream to an Airport Express. However, a thing that really could be
> cool is streaming Music from an iPhone to a computer running
> PulseAudio.

It's possibly something that fits better into VLC or GST etc, (just push
a stream to the sound output), although PA does provide a nice framework
for listening for it but I think the fact we'd only be able to
handle PCM easily (without linking to GST/VLC or similar), it may be
better implemented as a separate, but related project?

Not really sure to be honest.


If the whole crypography overhead can be skipped, in our current ROAP
output stuff tho', that would be a bonus. I guess it'll take some trial
and error experiments to work that out.


Col

-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

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

[pulseaudio-discuss] crackle and stutter

[Brian J. Murrell]

It seems inevitable that my pulse audio server
(0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 on Ubuntu Maverick)
will start sounding crackly and stuttery when an application wants to
send "notification" type sounds.

When this happens, about the only useful thing I see in the "-vvv"
output is:

D: alsa-sink.c: Requested to rewind 22988 bytes.
D: alsa-sink.c: Limited to 22988 bytes.
D: alsa-sink.c: before: 5747
D: alsa-sink.c: after: 5747
D: alsa-sink.c: Rewound 22988 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 22988 bytes on render memblockq.
D: sink-input.c: Have to rewind 22988 bytes on render memblockq.
D: sink-input.c: Have to rewind 11496 bytes on implementor.
D: source.c: Processing rewind...
D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 23120 bytes.
D: alsa-sink.c: Limited to 23120 bytes.
D: alsa-sink.c: before: 5780
D: alsa-sink.c: after: 5780
D: alsa-sink.c: Rewound 23120 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 23120 bytes on render memblockq.
D: sink-input.c: Have to rewind 23120 bytes on render memblockq.
D: sink-input.c: Have to rewind 11560 bytes on implementor.
D: source.c: Processing rewind...
D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 21480 bytes.
D: alsa-sink.c: Limited to 21480 bytes.
D: alsa-sink.c: before: 5370
D: alsa-sink.c: after: 5370
D: alsa-sink.c: Rewound 21480 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 21480 bytes on render memblockq.
D: sink-input.c: Have to rewind 21480 bytes on render memblockq.
D: sink-input.c: Have to rewind 10740 bytes on implementor.
D: source.c: Processing rewind...
D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 21848 bytes.
D: alsa-sink.c: Limited to 21848 bytes.
D: alsa-sink.c: before: 5462
D: alsa-sink.c: after: 5462
D: alsa-sink.c: Rewound 21848 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 21848 bytes on render memblockq.
D: sink-input.c: Have to rewind 21848 bytes on render memblockq.
D: sink-input.c: Have to rewind 10924 bytes on implementor.
D: source.c: Processing rewind...
D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 20212 bytes.
D: alsa-sink.c: Limited to 20212 bytes.
D: alsa-sink.c: before: 5053
D: alsa-sink.c: after: 5053
D: alsa-sink.c: Rewound 20212 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 20212 bytes on render memblockq.
D: sink-input.c: Have to rewind 20212 bytes on render memblockq.
D: sink-input.c: Have to rewind 10108 bytes on implementor.
D: source.c: Processing rewind...
D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 20336 bytes.
D: alsa-sink.c: Limited to 20336 bytes.
D: alsa-sink.c: before: 5084
D: alsa-sink.c: after: 5084
D: alsa-sink.c: Rewound 20336 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 20336 bytes on render memblockq.
D: sink-input.c: Have to rewind 20336 bytes on render memblockq.
D: sink-input.c: Have to rewind 10168 bytes on implementor.
D: source.c: Processing rewind...
D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
D: protocol-native.c: Requesting rewind due to rewrite.
D: alsa-sink.c: Requested to rewind 19012 bytes.
D: alsa-sink.c: Limited to 19012 bytes.
D: alsa-sink.c: before: 4753
D: alsa-sink.c: after: 4753
D: alsa-sink.c: Rewound 19012 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 19012 bytes on render memblockq.
D: sink-input.c: Have to rewind 19012 bytes on render memblockq.
D: sink-input.c: Have to rewind 9508 bytes on implementor.

I'm not really sure what this is telling me though.  Is the above
normal?  Is there something else I should be looking for?

During these periods of crackle and stutter, other "continuous" sound
output type applications, like audio/video apps seem to stutter as well
as if they are being blocked on their output by the pulse server and
it's attempting to handle these other "periodic" type applications that
send notification sounds and so on.

Thots?

b.



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

[pulseaudio-discuss] Weird bug with Pulseaudio connections.

[Robbie Smith]

Hello everyone

I haven't posted to this list before, not being much of a developer, but
I've been having some really odd bugs pop up almost at random with
Pulseaudio. Usually they disappear days or weeks later with just as much
warning as when they occur, and I'm never sure whether I've solved them
or whether my computer is just ... odd.

Anyway, the main nature of the bugs is that Pulseaudio seems to have
difficulty connecting to either ALSA, my sound card, or something else.
I can't quite explain what's going on; I've tried reading
through /var/log/errors.log and noticed that it is "failing to set
hardware parameters with a connection timeout". I'm not quite familiar
with how Pulseaudio works, but from the odd arcane messages I get, I'm
guessing that somewhere, somehow, it's trying to talk to my soundcard
and my soundcard is responding with "Computer says no."

The weird bit is that the "bug", if that's what it is, gets triggered by
almost anything. Commonly, opening pavucontrol will kill sound for a few
seconds to a few minutes: sound only resumes once I've killed
pavucontrol, and a dialog/error box will pop up alerting me to a
connection timeout. Given that pavucontrol is a really useful way of
manipulating the volume of individual programs this can be quite
annoying.

Before I describe what methods I've attempted to solve the problems,
I'll just briefly list my OS. I'm currently running Arch Linux, with (as
of tonight) the latest (stable) kernel 2.6.38.2 according to my update
logs. Pulseaudio itself is version 0.9.22. My desktop "environment" is
Openbox, and I'm calling it within consolekit and polkit and whatever
else it needs.

The command being called from ~/.xinitrc is
exec /usr/bin/ck-launch-session /usr/bin/openbox-session

start-pulseaudio-x11 is also being called in this file, a few
lines up.


As for setting up my system, I think I've tried just about every guide
there is, and there's a lot of conflicting information out there,
especially on user and group permissions. Sometimes following a guide
for the sake of it fixes the bug; that being said, I've already had the
settings it recommends so I have no idea what's going on.

I've experimented with setting sinks, with setting sound outputs,
everything. But time and again this weird bug shows up, pulseaudio fails
to load, or the pavucontrol applet brings the sound to a halt, or
something. And without warning it'll start working again, usually within
hours of me asking on a forum somewhere about the bug. 

As far as I know I've installed everything that might be needed. I used
to like Pulseaudio, the whole control-volume-of-individual-streams is
great. But it just doesn't work (between some of the time to most of the
time). And yet it's one of those features, which once you get used to
it, is really hard to live without.

How can I fix this once and for all? If there's any configuration
details or similar that you might need to be able to confirm or identify
the bug or whatever conditions are causing this, let me know what you
need to know and I'll try to assist in any way I can.

regards
Robbie

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

Re: [pulseaudio-discuss] [PATCH] stream-restore: Check for readability before reading volume

[Arun Raghavan]

On Tue, 2011-04-12 at 13:11 +0530, Arun Raghavan wrote:
> This avoids an assert in pa_sink_input_get_volume() when connecting a
> passthrough stream.

Based on Tanu's comments on the previous version of the patch, this one
should be correct.

-- Arun

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

[pulseaudio-discuss] [PATCH] stream-restore: Check for readability before reading volume

[Arun Raghavan]

This avoids an assert in pa_sink_input_get_volume() when connecting a
passthrough stream.
---
 src/modules/module-stream-restore.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/modules/module-stream-restore.c 
b/src/modules/module-stream-restore.c
index 9c94583..c984f18 100644
--- a/src/modules/module-stream-restore.c
+++ b/src/modules/module-stream-restore.c
@@ -1168,7 +1168,7 @@ static void subscribe_callback(pa_core *c, 
pa_subscription_event_type_t t, uint3
 created_new_entry = FALSE;
 }
 
-if (sink_input->save_volume) {
+if (sink_input->save_volume && 
pa_sink_input_is_volume_readable(sink_input)) {
 pa_assert(sink_input->volume_writable);
 
 entry.channel_map = sink_input->channel_map;
-- 
1.7.4.1

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