Re: sidcomp.audio test failure

Re: sidcomp.audio test failure

[Frank Ch. Eigler]

bje wrote:

: I tracked down a failure in the `linusraw.exp' test today.  [...]

Thanks.

: [...]  Instead, the test should perhaps keep polling the component
: until it has emptied its buffer and *then* check that the
: tx-sample-count is the correct value.  Thoughts?  [...]

Yup, makes sense.  Do your test logs include the following message?

        sid-io-audio: flushing buffers on tx close

That would indicate that insufficient polling was performed to fully
drain the output buffer.  While the "tx-pending" pin/attribute is
non-zero, the driver .exp file should tickle the component's "poll"
pin periodically, before finally turning off "tx-mode".

Unfortunately, I don't have any sound cards of small enough tx
capacity to test this the easiest possible way. :-)

- FChE

Re: sidcomp.audio test failure

[Ben Elliston]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

  Frank> : [...]  Instead, the test should perhaps keep polling the component
  Frank> : until it has emptied its buffer and *then* check that the
  Frank> : tx-sample-count is the correct value.  Thoughts?  [...]

  Frank> Yup, makes sense.  Do your test logs include the following message?

  Frank>         sid-io-audio: flushing buffers on tx close

Yes.

  Frank> That would indicate that insufficient polling was performed to fully
  Frank> drain the output buffer.  While the "tx-pending" pin/attribute is
  Frank> non-zero, the driver .exp file should tickle the component's "poll"
  Frank> pin periodically, before finally turning off "tx-mode".

  Frank> Unfortunately, I don't have any sound cards of small enough tx
  Frank> capacity to test this the easiest possible way. :-)

You can use my system -- I will turn the speakers down. :-)

Ben

sidcomp.audio test failure

[Ben Elliston]

I tracked down a failure in the `linusraw.exp' test today.  It's an
interesting one!  The problem is that the audio component uses
non-blocking I/O to write the audio data to /dev/audio.  On my older
Linux system with a cs4232 sound chipset, the test passes.  On my
newer system with a cs46xx chipset, the driver has a maximum write
size limitation of 32kb.

I have confirmed all of this by reading the drivers/sound/audio.c
source from the kernel.

Basically, I think this test is bogus.  It is a mistake to not
consider the possibility that the driver will return with any possible
value for the number of bytes written.  Instead, the test should
perhaps keep polling the component until it has emptied its buffer and
*then* check that the tx-sample-count is the correct value.  Thoughts?

In the meantime, I have marked the test as XFAIL.  It might fail, it
might not -- that depends on your OS and your sound hardware.  ;-(

Ben