Re: aplay garbled, but improved by mousing around (!!) ; -/

On 03/11/2012 07:41 AM Bengt Richter wrote:
> ISTM it might be some buffer-depletion event not triggering scheduling,
> but mousing around (i.e., left button down on mixer title bar and moving
> the window around) seems to trigger processing on some ignored queue and
> activation of some buffer-filling task, so sound samples can flow.
>
> Letting the mouse alone, buffering dies immediately and generates garbled
> echoey sound, maybe repeating last available buffer as output or who knows ...
>
> This is a new 4-penguin AMD box with 16gb ram:
>
> [05:00 ~]$ for x in s n r v m p i o;do echo -n $x:' '; uname -$x;done
> s: Linux
> n: zebra
> r: 2.6.37.6
> v: #3 SMP Sat Apr 9 22:49:32 CDT 2011
> m: x86_64
> p: AMD A8-3850 APU with Radeon(tm) HD Graphics
> i: AuthenticAMD
> o: GNU/Linux
>
> [ ... back later ...]
>
> BTW, there was no sound until I added this file,
> (apparently to bump default from card 0 which didn't work):
>
> [07:19 ~]$ cat ~/.asoundrc
> pcm.!default {
> type hw
> card 1
> }
>
> ctl.!default {
> type hw
> card 1
> }
>
> But otherwise this is as-is off the 13.37 DVD, 64-bit side.
>
> Anyone else experienced these symptoms? I see there is something
> new in alsa since 13.37's Apr 9 22:49:32 CDT 2011 date:
>
> 	http://www.alsa-project.org/main/index.php/Main_Page
> in the project news box:
> 	2012-01-25      alsa 1.0.25 release | Changes v1.0.24 v1.0.25
> link:	http://www.alsa-project.org/main/index.php/Changes_v1.0.24_v1.0.25
>
> Could there be a fix in there?
>
> TIA for any clues, in case someone knows and can save me searching ;-)
>
> Regards,
> Bengt Richter

Sorry to follow up on my own post, but just to add that the mouse has
nothing to do with making the sound better, nor GUI busyness -- just busyness:

I exited KDE and aplay from the tty command line was similarly garbled, until
I logged into another (tty2) session and started a monster scrolling
recursive ls of the entire file system there. Then sound started to clarify.
Another session at tty3 improved things slightly more. Once the listing
started, I didn't have to touch the computer. Nor did it make any difference
which shell I was looking at (e,g, going back to tty1 where I kicked off aplay).

Actually, I used lsc (a wrapper for ls that I wrote to commafy the ls file size field
and sed out some stuff, and use iso time format with seconds, to look like, e.g.,

[02:17 ~]$ lsc /boot
       15,634 2011-03-26 22:32:39 slack.bmp
       17,932 2011-03-26 23:53:11 diag2.img
        5,040 2011-03-26 23:53:11 diag1.img
    2,956,592 2011-04-09 11:25:01 vmlinuz-generic-2.6.37.6
      112,324 2011-04-09 11:25:01 config-generic-2.6.37.6
    1,782,099 2011-04-09 11:25:01 System.map-generic-2.6.37.6
    5,866,144 2011-04-09 20:50:07 vmlinuz-huge-2.6.37.6
      112,298 2011-04-09 20:50:07 config-huge-2.6.37.6
    2,706,772 2011-04-09 20:50:07 System.map-huge-2.6.37.6
           21 2012-02-15 10:49:49 vmlinuz -> vmlinuz-huge-2.6.37.6
           20 2012-02-15 10:49:49 config -> config-huge-2.6.37.6
           24 2012-02-15 10:49:49 System.map -> System.map-huge-2.6.37.6
          209 2012-02-15 10:52:07 boot_message.txt
          512 2012-02-15 10:52:09 boot.0800
           37 2012-02-16 09:36:30 README.initrd -> /usr/doc/mkinitrd-1.4.6/README.initrd
       92,160 2012-02-18 21:22:23 map

), and that creates enough busyness, being a horrible hack with multiple pipes and calls to sed
in a read loop and a separate commafy ommand, etc., but I tried plain ls, and that is apparently
too efficient since it doesn't involve bash and all that nonsense. So you may have to use more
sessions of ls listing or other file-activity-inducing commands to duplicate my lsc busyness.

Maybe all the activity includes a path that polls audio buffer state, but somehow
no hardware event per se (e.g. one of a chain of buffers being used up by DMA, ultimately)
was being waited for to trigger buffer-filling. Or some chain of software-generated events
not hooked up properly after ~/.asoundrc switched from default card 0 (which was silent for
other reasons, I think)?

I installed with the ext4 file system, BTW, and I guess there could be interaction in
reading the wav file and reading directories for the big scrolling listing... I'll try
some busyness that doesn't read from the disk ...

Aha! I started an endless computing of the digits of pi, output to the screen in tty2,
and that had no noticeable effect, but when I did ls -ltr / in tty3, the sound clarified.
So it seems that it may have to do with file reading events. Wonder if ext2 would have the
same problem. ... Maybe it's not an ALSA problem?

That's all I have for now. TIA for any clues.

Regards,
Bengt Richter