Bug 462925

Summary: 0.9.12 doesn't play nice with e16, no sounds come out...
Product: [Fedora] Fedora Reporter: Valdis Kletnieks <valdis.kletnieks>
Component: pulseaudioAssignee: Lennart Poettering <lpoetter>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: lkundrak, pierre-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-06 17:36:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Valdis Kletnieks 2008-09-19 19:06:48 UTC
Description of problem:
The e16 window manager worked just fine against pulseaudio 0.9.10, but fails to produce sound alerts on 0.9.11 or 0.9.12.  Against 0.9.12, the pulseaudio daemon
logs this:

I: client.c: Created 3 "EsounD client (UNIX socket client)"
D: core-scache.c: Created sample "esound./home/valdis/.e16/themes/TurboCandy/sound/samples/SOUND_FOCUS_SET.wav" (#1), 0 bytes with sample spec Invalid
D: core-scache.c: Created sample "esound./home/valdis/.e16/themes/TurboCandy/sound/samples/SOUND_FOCUS_SET.wav" (#1), 25630 bytes with sample spec s16le 
1ch 44100Hz
D: core-scache.c: Playing sample "esound./home/valdis/.e16/themes/TurboCandy/sound/samples/SOUND_FOCUS_SET.wav" on "alsa_output.hw_0"
D: memblockq.c: memblockq requested: maxlength=25630, tlength=0, base=2, prebuf=1, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=25630, tlength=25630, base=2, prebuf=2, minreq=2 maxrewind=0
D: sink-input.c: Assertion 'pa_channel_map_valid(&data->channel_map)' failed at pulsecore/sink-input.c:150, function pa_sink_input_new.
D: core-scache.c: Playing sample "esound./home/valdis/.e16/themes/TurboCandy/sound/samples/SOUND_FOCUS_SET.wav" on "alsa_output.hw_0"
D: memblockq.c: memblockq requested: maxlength=25630, tlength=0, base=2, prebuf=1, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=25630, tlength=25630, base=2, prebuf=2, minreq=2 maxrewind=0
D: sink-input.c: Assertion 'pa_channel_map_valid(&data->channel_map)' failed at pulsecore/sink-input.c:150, function pa_sink_input_new.
D: core-scache.c: Playing sample "esound./home/valdis/.e16/themes/TurboCandy/sound/samples/SOUND_FOCUS_SET.wav" on "alsa_output.hw_0"
D: memblockq.c: memblockq requested: maxlength=25630, tlength=0, base=2, prebuf=1, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=25630, tlength=25630, base=2, prebuf=2, minreq=2 maxrewind=0
D: sink-input.c: Assertion 'pa_channel_map_valid(&data->channel_map)' failed at pulsecore/sink-input.c:150, function pa_sink_input_new.
D: core-scache.c: Playing sample "esound./home/valdis/.e16/themes/TurboCandy/sound/samples/SOUND_FOCUS_SET.wav" on "alsa_output.hw_0"
D: memblockq.c: memblockq requested: maxlength=25630, tlength=0, base=2, prebuf=1, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=25630, tlength=25630, base=2, prebuf=2, minreq=2 maxrewind=0
D: sink-input.c: Assertion 'pa_channel_map_valid(&data->channel_map)' failed at pulsecore/sink-input.c:150, function pa_sink_input_new.
D: core-scache.c: Removed sample "esound./home/valdis/.e16/themes/TurboCandy/sound/samples/SOUND_FOCUS_SET.wav"
D: protocol-esound.c: read(): EOF
I: client.c: Freed 3 "EsounD client (UNIX socket client)"

So something is causing it to throw an assert - even though that same exact sound sample worked fine on esd, and on previous pulseaudio releases.

Version-Release number of selected component (if applicable):
pulseaudio-0.9.12-6.fc10.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Valdis Kletnieks 2008-09-19 19:10:13 UTC
Oh - I forgot to mention that I tried both my original e16 binary that was built against pulseaudio-devel 0.9.10, and also recompile against the 0.9.12 headers, and both failed the same way.  If there was an API change, the .so level should have been revved or something...  so I'm considering this as something that worked, and absent an API change, should continue working...

Comment 2 Lennart Poettering 2008-09-23 23:55:32 UTC
Hmm, how many channels do those wave files have?

Comment 3 Valdis Kletnieks 2008-09-24 15:45:20 UTC
Several different sample sizes and speeds, but all mono:

% file * | cut -c37- | sort -u
RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 22050 Hz
RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz
RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 11025 Hz
RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 44100 Hz

Comment 4 Lennart Poettering 2008-10-03 20:26:42 UTC
I am pretty sure I fixed this now in rc0815deb4add5ae4598de7c2c0589d1f5dc1c641 in the upstream git repo. Will upload a new version to Fedora soon.

Comment 5 Lennart Poettering 2008-10-06 17:36:48 UTC
Fxied in 0.9.13-1

Comment 6 Valdis Kletnieks 2008-10-06 19:28:50 UTC
Confirmed fixed in 0.9.13-1, thanks...