2 May
2003
2 May
'03
6:43 a.m.
HI!
I'm trying to write very simple software synthesizer under Linux just for my
own educational purpose.
but one problem i came over is the following:
I made the audio thread shced_fifo with max priority. My GUI thread is
sched_other. To allow the GUI to rerspond, I thought i could just put the
audio thread to sleep for the playing length of the buffer (7ms). But the
minimum tick interval of the linux scheduler is 10ms and its not even sure
that the thread will sleep for exact 20ms. So how can I avoid underruns if
the timing is so unreliable?
Thanks in advance
Alex
2 May
2 May
8:25 a.m.
Hi,
On Fri, May 02, 2003 at 10:51:27AM +0200, Alexander Lenhardt wrote:
but one problem i came over is the following:
I made the audio thread shced_fifo with max priority. My GUI thread is
sched_other. To allow the GUI to rerspond, I thought i could just put the
audio thread to sleep for the playing length of the buffer (7ms). But the
minimum tick interval of the linux scheduler is 10ms and its not even sure
that the thread will sleep for exact 20ms. So how can I avoid underruns if
the timing is so unreliable?
What about simply using a bigger buffer?
But there are other things, which can delay even longer (other
applications, swapping, disk spinup etc.).
Remember, we are in a multitasking, multiuser environment here.
Regards
Ingo Oeser
8:39 a.m.
On Fri, May 02, 2003 at 10:51:27AM +0200, Alexander Lenhardt wrote:
I'm trying to write very simple software
synthesizer under Linux just for my
own educational purpose.
but one problem i came over is the following:
I made the audio thread shced_fifo with max priority. My GUI thread is
sched_other. To allow the GUI to rerspond, I thought i could just put the
audio thread to sleep for the playing length of the buffer (7ms).
There's something fundamentally wrong here. Normally, the audio thread
synchronises with the audio (ALSA) driver. It will be waiting most of the
time, giving other threads a chance to run, and the problem you describe
then does not exist. This is really the first thing you should get right.
FA
9:43 a.m.
On Fri, May 02, 2003 at 10:51:27AM +0200, Alexander
Lenhardt wrote:
<ObJack>
if you use the JACK Audio Connection Kit (http://jackit.sf.net/) you
won't have to worry about any of this stuff. you just write the code
to generate chunks of audio, and JACK takes care of just about
everything else. in addition, if you simple software synth mutates
into something more interesting, it will then be able to route audio to the
many other applications that use JACK.
</ObJack>
I'm trying to write very simple software
synthesizer under Linux just for my
own educational purpose.
but one problem i came over is the following:
I made the audio thread shced_fifo with max priority. My GUI thread is
sched_other. To allow the GUI to rerspond, I thought i could just put the
audio thread to sleep for the playing length of the buffer (7ms).
There's something fundamentally wrong here. Normally, the audio thread
synchronises with the audio (ALSA) driver. It will be waiting most of the
time, giving other threads a chance to run, and the problem you describe
then does not exist. This is really the first thing you should get right.
10:37 a.m.
On Fri, May 02, 2003 at 07:38:04AM -0400, Paul Davis wrote:
<ObJack>
....
</ObJack>
Hi Paul,
Agreed, but given the number of small but annoying problems JACK
has recently experienced (see activity on the list), this is *not*
a thing I'd recommend to someone who is clearly setting his first
brave steps into the minefield of multithreaded real-time programming,
and who is doing so 'for his own educational purposes'. If someone
is prepared to enter into this field, I'd give him/her time to learn.
Fons
11 a.m.
Agreed, but given the number of small but annoying
problems JACK
has recently experienced (see activity on the list), this is *not*
a thing I'd recommend to someone who is clearly setting his first
brave steps into the minefield of multithreaded real-time programming,
and who is doing so 'for his own educational purposes'. If someone
is prepared to enter into this field, I'd give him/her time to learn.
i broadly agree with you. however, the question is whether s/he wants
to learn about software synthesis or interacting with a HAL for audio
interfaces. if the former, then i still tend to feel that despite the
recent small but annoying problems with JACK, such a a person is
better off avoiding the HAL layer and working at the level of
abstraction that JACK provides. if they want to learn everything, then
sure, just do it all themselves.
11:09 a.m.
On Fri, 2 May 2003, Alfons Adriaensen wrote:
On Fri, May 02, 2003 at 07:38:04AM -0400, Paul Davis
wrote:
I think you are totally overexaggerating the resent problems. Infact, I
think using the jack is the best advice to give. Its a simple and powerful
API included with small and easy-to-understand example programs.
--
<ObJack>
....
</ObJack>
Hi Paul,
Agreed, but given the number of small but annoying problems JACK
has recently experienced (see activity on the list), this is *not*
a thing I'd recommend to someone who is clearly setting his first
brave steps into the minefield of multithreaded real-time programming,
and who is doing so 'for his own educational purposes'. If someone
is prepared to enter into this field, I'd give him/her time to learn.
11:51 a.m.
On Fri, May 02, 2003 at 02:59:04PM +0200, Kjetil S. Matheussen wrote:
I think you are totally overexaggerating the resent
problems.
'small but annoying problems' ???
There are only two degrees lower than this:
- 'tiny and charming problems'
- 'features'
and many many degrees above :-)
I think using the jack is the best advice to give. Its
a simple and powerful
API included with small and easy-to-understand example programs.
It depends. For someone who wants to write an application, yes.
For someone who wants to learn the basics, no. Such a person should
study JACK's code, not use it.
FA
12:33 p.m.
Alfons Adriaensen <fons.adriaensen(a)alcatel.be> writes:
'small but annoying problems' ???
There are only two degrees lower than this:
- 'tiny and charming problems'
- 'features'
and many many degrees above :-)
For the record, I'd like to point out that all the recent problems
with JACK (annoying, charming, or otherwise) were all in intermediate
CVS versions.
JACK releases have been quite stable. That is a significant
accomplishment, considering the delicate realtime and concurrency
issues that arise in this kind of code.
IMHO, someone writing Linux audio code for the first time would do
well to start with a stable JACK release.
Regards,
--
Jack O'Quin
Austin, Texas, USA
6:22 p.m.
Hi Paul!
<ObJack>
...
</ObJack>
This might be right in terms of "don't reinvent the wheel if it already
exists". But i am more interested in the fundamentals. So my final goal is
to implement a simple audio engine which has a latency below 15ms avg..
Using JACK would do this for me, but then I still don't know anything about
the foundamental design concepts of a realtime audio engine.
But thanks for your answer!
Alex
7909
days inactive
7909
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Alexander Lenhardt -
Alfons Adriaensen -
Ingo Oeser -
Jack O'Quin -
Kjetil S. Matheussen -
Paul Davis