Hugging Face's logo

Spaces:
amarchheda
/
ChordDuplicate
Runtime error

App Files Community
ChordDuplicate
File size: 3,111 Bytes 
83418c6
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
 
From: "Benno Senoner" <[email protected]>
To: <[email protected]>
Subject: Re: [music-dsp] coding realtime guitar efx on a "pc"
Date: Saturday, June 30, 2001 8:19 AM


Andr�,
you are solving your problem the wrong way:
you need to use a single threaded solution which does this:

- set the audio I/O parameters to  fragnum=4  fragsize=128 bytes (=32samples) if
you use stereo or   fragsize=64 bytes (=32 samples) if you use mono.

(do not forget to activate fulltuplex with using the _TRIGGER_ stuff)
(you need to frist deactivate audio and then start the trigger after the DAC is
prefilled (see below))

This will give you a total input to output latency of 4x32 samples
= 128 samples which at 44.1kHz correspond to 2.9msec latency.

now set your process to SCHED_FIFO  (see man sched_setscheduler)

after the initialization your code should do more than less this:

- write()  4 x 32 samples to the audio fd in order to prefill the DAC.
Without this you will get dropouts.

while(1) {
  read() 32 samples from ADC
  perform_dsp_stuff() on the 32 samples
  write() 32 samples  to DAC
  }

If you use a low latency kernel and pay attention to all the stuff above, then
you will get rock solid 3msec latencies (plus eventual converter latencies but
these are in the 1-2msec range AFAIK).

Using multiple threads , pipes etc, only complicates your life and often makes
it impossible to achieve these low latences.

Realtime/audio programming is not an easy task , this is why people often
fail to get the desired results even if their hardware is low-latency capable.

The problem is that the final latency depends on the hardware you use,
the application and the operating system.

cheers,
Benno.

http://www.linuxaudiodev.org  The Home of Linux Audio Development






On Sat, 30 Jun 2001, you wrote:
> On 2001-06-29 21:38 +0200, Benno Senoner wrote:
> 
> > OSS/Free refuses to use a low # of frags ?
> > 
> > That's a myth.
> 
> I hope it is. :-)
> 
> The fact is that ioctl(SNDCTL_DSP_SETFRAGMENT) succeeds with
> values as low a 0x10007 (one 128-B fragment) but the latency is
> still high enough to be clearly noticeable, which suggests that
> it's *way* above 2/3 ms.  This is on an otherwise idle machine
> equipped with a SB PCI 128.
> 
> But maybe it's me who's doing something wrong. I've been careful
> to flush stdio buffers or use unbuffered I/O (write(2)) but I
> may have let something else through.
> 
> For example, since the signal processing and the I/O are done by
> two different vanilla processes communicating via pipes, it may
> be a scheduling granularity problem (E.G. the kernel giving the
> I/O process a time slice every 20 ms).
> 
> -- 
> Andr� Majorel <[email protected]>
> http://www.teaser.fr/~amajorel/
> 
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
-- 


dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
http://shoko.calarts.edu/musicdsp/