Re: kern/39204: pad(4) device doesn't emit PCM data

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR kern/39204; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/39204: pad(4) device doesn't emit PCM data
Date: Mon, 16 Apr 2012 18:38:15 -0400

 On Thu, 22 Mar 2012 09:30:06 +0000 (UTC)
 Matthew Mondor <mm_lists%pulsar-zone.net@localhost> wrote:
 
 > The following reply was made to PR kern/39204; it has been noted by GNATS.
 > 
 > From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: 
 > Subject: Re: kern/39204: pad(4) device doesn't emit PCM data
 > Date: Thu, 22 Mar 2012 05:29:31 -0400
 > 
 >  Please see related kern/46232 for the panic problem
 
 The panic issue in kern/46232 should now be fixed.  As for the other
 issue I had with broken data, I think that this PR seems related.
 
 However, I just did a test now and interestingly I didn't get obviously
 broken data:
 
 I first started a dd command to dump pad0 to file, which as expected
 blocks waiting for data:
 
 dd if=/dev/pad0 of=pad.raw
 
 Then I started another process to generate some audio to the audio1
 device:
 
 mplayer -ao sun:/dev/audio1 foo.mp4
 
 Which I left running a bit, while it was possible to see the pad.raw
 file growing.  I then stopped this last process after a minute or so,
 and noticed that the pad.raw file was no longer growing, the dd process
 blocking for more data.  I then killed the dd process.
 
 I then tested the result by playing pad.raw:
 
 audioplay -f -e slinear_le -P 16 -c 2 -s 44100 pad.raw
 
 And this time there seemed to be problem whatsoever.  I then reiterated
 the process a second time, and the results still seemed fine.
 
 A third time, this time playing an ogg-vorbis file with mplayer, in
 which case the results were only slightly skipping.  A fourth time,
 playing an mp3, also with slight skipping approximately 3 times a
 second.
 
 A fith test, this time with an mp4 like for the first, but another
 one.  I also could hear small skipping.  It's possible that skipping
 did occur in the first two tests, but that I couldn't hear it because
 of the type of music.  In any case, it wasn't huge skipping anymore as
 I had described in kern/46232.
 
 The last test I did was playing a single-channel audio wav file to
 audio1.  In this case, the time required to play it was much longer
 than expected, at which point I stopped the process with a break.
 Interestingly, only about half a second of output have been recorded.
 I remember being able to play mono samples while recording from pad0,
 in which case the first channel seemed duplicated on the second, with
 the pad(4) output always stereo (see kern/44677).
 
 Where skipping occurs, the bytes are still set at 0x00.  By looking at
 the data, I could see two such skip of exactly 1024 bytes, but didn't
 check if all other gaps were this size.  According to dd, the default
 block size would be 512.  If I try using cat(1) rather than dd(1), I
 only get a huge file of 0x00 bytes created at the maximum speed the
 disk allows, whenever writing to audio1 occurs.
 -- 
 Matt