On Fri, 05.09.08 07:10, Kevin Gilbert (kevin952 at tpg.com.au) wrote:
Heya!
> --
Why did you put these two dashes here? For most intelligent mailers
this is a sign that the signature begins below and they hence remove
everything below it on reply. When I tried to reply to your mail all I
got was an empty text. Very very confusing. ;-)
> D: alsa-util.c: snd_pcm_dump():
> D: alsa-util.c: Soft volume PCM
> D: alsa-util.c: Control: PCM Playback Volume
> D: alsa-util.c: min_dB: -51
> D: alsa-util.c: max_dB: 0
> D: alsa-util.c: resolution: 256
> D: alsa-util.c: Its setup is:
> D: alsa-util.c: stream : PLAYBACK
> D: alsa-util.c: access : MMAP_INTERLEAVED
this is interesting ^^^^^^^^^^^^^^^^
> D: alsa-util.c: format : S16_BE
> D: alsa-util.c: subformat : STD
> D: alsa-util.c: channels : 2
> D: alsa-util.c: rate : 44100
> D: alsa-util.c: exact rate : 44100 (44100/1)
> D: alsa-util.c: msbits : 16
> D: alsa-util.c: buffer_size : 4096
> D: alsa-util.c: period_size : 256
> D: alsa-util.c: period_time : 5804
> D: alsa-util.c: tstamp_mode : NONE
> D: alsa-util.c: period_step : 1
> D: alsa-util.c: avail_min : 12853
> D: alsa-util.c: period_event : 0
> D: alsa-util.c: start_threshold : -1
> D: alsa-util.c: stop_threshold : -1
> D: alsa-util.c: silence_threshold: 0
> D: alsa-util.c: silence_size : 0
> D: alsa-util.c: boundary : 1073741824
> D: alsa-util.c: Slave: Hardware PCM card 0 'PS3' device 0 subdevice 0
> D: alsa-util.c: Its setup is:
> D: alsa-util.c: stream : PLAYBACK
> D: alsa-util.c: access : MMAP_NONINTERLEAVED
and this is interesting, too ^^^^^^^^^^^^^^^^^^^
> D: alsa-util.c: format : S16_BE
> D: alsa-util.c: subformat : STD
> D: alsa-util.c: channels : 2
> D: alsa-util.c: rate : 44100
> D: alsa-util.c: exact rate : 44100 (44100/1)
> D: alsa-util.c: msbits : 16
> D: alsa-util.c: buffer_size : 4096
> D: alsa-util.c: period_size : 256
> D: alsa-util.c: period_time : 5804
> D: alsa-util.c: tstamp_mode : NONE
> D: alsa-util.c: period_step : 1
> D: alsa-util.c: avail_min : 12853
> D: alsa-util.c: period_event : 0
> D: alsa-util.c: start_threshold : -1
> D: alsa-util.c:
> D: module-alsa-sink.c: Read hardware volume: 0: 100% 1: 100%
> D: module-alsa-sink.c: Thread starting up
> D: rtpoll.c: Acquired POSIX realtime signal SIGRTMIN+29
> E: module-alsa-sink.c: Assertion '(areas[0].step >> 3) == u->frame_size' failed at modules/module-alsa-sink.c:320, function mmap_write(). Aborting.
and this as well ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Certainly appears to be getting better but I'll leave the forensics up to the
> experts.
So, what happens here is this: your device can only do non-interleaved
audio and is hence configured for it (as we can see from that "slave
setup" listing above). Because your hardware lacks a hardware volume
control ALSA puts "softvol" on top of the hw device: the "Soft Volume
PCM" you can see in the first part. That device is initialized for
interleaved audio as you can see. Which is what PA supports and PA
asked for.
Now, if softval takes non-interleaved from below and gives interleaved
to the layer above than it would need to rearrange those samples --
which it however doesn't actually. PA hence checks with those asserts
if the audio data is properly arranged -- which it is not as we can
see.
This is a bug in ALSA's softvol module. Please report this on
alsa-devel. softvol falsely claims to be able to rearrange
non-interleaved audio to interleaved.
(and make sure to post on alsa-devel, don't use the alsa BTS. The BTS
is mostly ignored...)
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
