#28 reading lots of 0's at beginning  Edit

emu10k1
closed
recording (4)
5
2012-07-08
2002-06-06
Peter Gober
No

Hi there,

The following test program


include <fcntl.h>

include <stdio.h>

include <sys/soundcard.h>

main()
{
unsigned char *buf[8192];
int i,r, audio_fd;

if ((audio_fd = open("/dev/dsp", O_RDONLY, 0)) < 0)
printf("Cannot open OSS audio device %s", "/dev/dsp");

r = read(audio_fd, buf, 8192);
printf("read %d samples, ", r);
for (i = 0; i < r; i++) {
if (buf[i] != 0)
break;
}
printf("the first %d of which are 0\n ", i);
}


reproducibly produces the output

 read 8192 samples, the first 7226 of which are 0

Sometimes, the 7226 is a 0, but never another number.

So obviously, this is a bug in the recording mechanisam
producing a number of 0's when starting recording. This
bug may look unimportant at first sight. But my audio
input produces a lot of static noise, and the silence
detector of a speech recognizer takes the 0's as the
"silence level" and my static noise as the "speech
level", therefore never detecting silence after start.

My configuration: Soundblaster Live!, Red Hat Kernel
2.4.9-31. The problem seems to apply both to the
emu10k1 and emu10k1_new modules, that come from Red
Hat, as well as the new emu10k1-v0.19a.

Peter

Discussion

  • Rui Sousa

    Rui Sousa - 2002-06-08

    Logged In: YES
    user_id=3329

    This is a bug:
    unsigned char *buf[8192];

    it should be simply:
    unsigned char buf[8192];

    Does it fix your problem?
    What are you recording?

     
  • Peter Gober

    Peter Gober - 2002-06-08

    Logged In: YES
    user_id=370024

    Yes, this was a bug in the test program. Thank you.

    But this doesn't affect my problem. (I detected the bug in a
    larger program and introduced this bug when writing a this
    small test program.)

    Now I have:


    include <fcntl.h>

    include <stdio.h>

    include <sys/soundcard.h>

    main()
    {
    unsigned char buf[16384];
    int i,r, audio_fd;

    if ((audio_fd = open("/dev/dsp", O_RDONLY, 0)) < 0)
    printf("Cannot open OSS audio device %s", "/dev/dsp");
    r = read(audio_fd, buf, 16384);
    printf("read %d samples, ", r);
    for (i = 0; i < r; i++) {
    if (buf[i] != 0)
    break;
    }
    printf("the first %d of which are 0\n ", i);
    }


    And I mostly get

    "read 16384 samples, the first 12288 of which are 0",

    sometimes I get 0 instead of 12288, but never another
    number. It can't be just chance, that always the first 12288
    samples are 0.

    It makes no difference, what I try to record! I could
    reproduce that problem on different computers and got a
    report from someone else obviously having the same problem,
    so I pretty much expect, this test program will reveal the
    suspected bug on almost and Creative Live!/emu10k1 installation.

    Could that problem be a duplicate/related to 514380?

    Peter

     
  • Peter Gober

    Peter Gober - 2002-06-08

    Logged In: YES
    user_id=370024

    One additional remark:

    I discovered that magic "12288" (which I get as the number
    of leading 0's) within the emu10k1 sourcecode. It seems to
    be an internal buffer size:

    define ADCBS_BUFSIZE_12288 0x00000015

    Does that help?

    Peter

     
  • Rui Sousa

    Rui Sousa - 2002-06-10

    Logged In: YES
    user_id=3329

    Can you try the program "rec" in emu10k1/utils/oss-test?
    Edit the common.h file and set WRITE_FILE to 1. The recorded
    data
    will be placed in (text file 1 column per channel) "output.dat".

    Does it also show a bunch of zeros at the beginning?

     
  • Peter Gober

    Peter Gober - 2002-06-10

    Logged In: YES
    user_id=370024

    Thank you very much for taking a look at my problem.

    After running rec, output.dat contains:

    0 0
    0 0
    ... (exactly 12288 times) ...
    0 0
    0 0
    -21 511
    -23 767
    -18 -1537
    -18 255
    -21 255
    ...

    So we have the bunch of zeroes again.

    Peter

     
  • Rui Sousa

    Rui Sousa - 2002-06-10

    Logged In: YES
    user_id=3329

    Ok. So edit common.h again and set DEBUG to 1. Compile and
    run rec again with:

    ./rec > log

    Press "Enter" twice, wait a couple of seconds, then Ctrl+C.
    Finally attach the contents of the log file, just enough
    lines until you see:

    (SNDCTL_DSP_GETIPTR)
    bytes: 8064 blocks: 15 ptr: 8064 ret: 0

    with bytes ~= 3 * 12288

     
  • Peter Gober

    Peter Gober - 2002-06-11

    Logged In: YES
    user_id=370024

    SELECTED FORMAT
    (SNDCTL_DSP_SETFMT)
    format: 16 ret: 0

    (SNDCTL_DSP_CHANNELS)
    channels: 2 ret: 0

    (SNDCTL_DSP_SPEED)
    speed: 48000 ret: 0

    SELECTED BUFFER
    (SNDCTL_DSP_SETFRAGMENT)
    size: 256 number: 100 ret: 0

    ACTUAL BUFFER
    (SNDCTL_DSP_GETBLKSIZE)
    fragsize: 256 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 0 fragstotal: 96 fragsize: 256 bytes: 0 ret: 0

    (SNDCTL_DSP_GETIPTR)
    bytes: 0 blocks: 0 ptr: 0 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 0 fragstotal: 96 fragsize: 256 bytes: 0 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 25024 blocks: 97 ptr: 448 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 81 fragstotal: 96 fragsize: 256 bytes: 20928 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 25440 blocks: 2 ptr: 864 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 67 fragstotal: 96 fragsize: 256 bytes: 17248 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 25888 blocks: 2 ptr: 1312 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 53 fragstotal: 96 fragsize: 256 bytes: 13600 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 26304 blocks: 1 ptr: 1728 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 38 fragstotal: 96 fragsize: 256 bytes: 9920 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 26752 blocks: 2 ptr: 2176 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 24 fragstotal: 96 fragsize: 256 bytes: 6272 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 27168 blocks: 2 ptr: 2592 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 10 fragstotal: 96 fragsize: 256 bytes: 2592 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 29536 blocks: 9 ptr: 4960 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 3 fragstotal: 96 fragsize: 256 bytes: 864 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 33376 blocks: 15 ptr: 8800 ret: 0

    (SNDCTL_DSP_GETISPACE)
    fragments: 2 fragstotal: 96 fragsize: 256 bytes: 608 ret: 0

    (read)
    count: 4096 ret: 4096

    (SNDCTL_DSP_GETIPTR)
    bytes: 37472 blocks: 16 ptr: 12896 ret: 0
    ...

     
  • Rui Sousa

    Rui Sousa - 2002-08-12

    Logged In: YES
    user_id=3329

    Finally had some time (and the hardware) to try to reproduce
    this. In my Celeron 366Mhz this was somewhat hard to
    reproduce but it should now be fixed in mainline CVS. If
    it's still broken:

    What is your CPU speed?
    Can you play around with the udelay() in
    recmgr.c:emu10k1_start_record() and report back which value
    of delay works reliably for you?

     
  • Peter Gober

    Peter Gober - 2002-08-13

    Logged In: YES
    user_id=370024

    Thank you very much for working on that problem.

    For me, with your udelay(10) the situation improved (~50 %
    error probability), with udelay(50) even more (~5 %) and now
    I have udelay(100) with no problems any more. I have an
    Athlon with 1 GHz.

    A delay of .0001 seconds prior to recording shouldn't be
    that bad. On the other hand: Isn't there a way to reliably
    check, when the chip is ready or whatever?

    Again, thank you very much.

     
  • Rui Sousa

    Rui Sousa - 2002-08-14

    Logged In: YES
    user_id=3329

    I did a new fix. Now we wait in a busy loop until the
    hardware is properly reset
    (which for me takes <~ 10us) as you suggested. Also now if
    you use SNDCTL_DSP_SETTRIGGER to start recording you won't
    be affected by this delay.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks