[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/39204: pad(4) device doesn't emit PCM data
The following reply was made to PR kern/39204; it has been noted by GNATS.
From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
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
> 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
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
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
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.
Main Index |
Thread Index |