linux-kernel - Re: PROBLEM: SIS7019 stops recording after 42 min

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikW71h7ABVXY21pLL9AeOlmRTfVaSTjJ_6Ma0_R@mail.gmail.com>
Date:	Mon, 21 Jun 2010 19:42:38 +0200
From:	Hans Schou <linux@...ou.dk>
To:	David Dillow <dave@...dillows.org>
Cc:	linux-kernel@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: PROBLEM: SIS7019 stops recording after 42 min

2010/6/21 David Dillow <dave@...dillows.org>:

>> Only 35 minutes of recording but I was running in 50min.
>
> Ok, cool, we see the problem with arecord as well, though you were
> getting overrun messages as well?

Yes, a lot of overrun. At least one per second.

>> How do I enable SND_PCM_XRUN_DEBUG with sox?
>
> Sorry, that should be CONFIG_SND_PCM_XRUN_DEBUG in the kernel
> configuration, but if we can demonstrate this with arecord, there's no
> real reason to recompile your kernel at this point.

OK, I'll skip that. It takes rather long time to compile.

>> Right now uptime says
>>    load average: 0.19, 0.21, 0.18
>> but strace and top is the bad guys, not arecord.
>
> An overrun means that arecord didn't run for 500ms, and the load average
> won't really tell you much about that -- latency can happen with low

Well, I did not see that with sox. It was running fine for 42 min.

> loads. That said, I'm suspecting that you've found a problem in the
> driver, and I'd lay odds it is in the handling of multiple periods per
> buffer.

> I don't know the options available on sox, but if you can use arecord to
> reproduce, then that is probably the best tool for the job. Can you set
> it up to use two periods per buffer and see if you still can reproduce?
> Options would look like -B 250000 -F 125000. A second test with -B
> 1000000 -F 500000 would be interesting, if the hw can handle buffers of
> that size -- I don't recall offhand.

I have just started it with  -B 250000 -F 125000 and get a lot of overrun.
I skipped using strace to make less stress.

cmdline is now:
arecord -B 250000 -F 125000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav

overrun!!! (at least 0.201 ms long)
Status:
  state       : XRUN
  trigger_time: 1277140527.1826705
  tstamp      : 1277140527.2005279
  delay       : 0
  avail       : 16537
  avail_max   : 16537
overrun!!! (at least 0.207 ms long)
Status:
  state       : XRUN
  trigger_time: 1277140527.128608572
  tstamp      : 1277140527.128793445
  delay       : 0
  avail       : 16537
  avail_max   : 16537
overrun!!! (at least 0.167 ms long)
Status:
  state       : XRUN
  trigger_time: 1277140527.256925501
  tstamp      : 1277140527.257071819
  delay       : 0
  avail       : 16537
  avail_max   : 16537

> I will hopefully have my hardware back up and running tonight; BTW, what
> distro are you using? I'm trying Fedora 13, but I'm expecting to run
> into trouble with the lack of cmov support on the processor.

Debian stable.

/hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/