Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Ray Rashif 
2009/9/24  

> About the rt kernels:
> We don't have as much experience as Fernando, so the rt kernels
> are probably not as tuned yet, but since it's trivial to make config
> changes and compile/install kernels that could change quickly. The
> current rt kernels are based on the vanilla kernels and unpatched
> (except for some ATI graphics compatibility), which is a little plus I
>  guess.


Uhmm no. That is a decision we made to keep in sync with KISS, while less is
definitely better in the case of kernels. We patch only as needed, and all
ammendments against the stock kernel are documented in the changelogs.
Practically, there are no further "tunables" aside from removing unneeded
options and modules. Some users probably already have their own tried and
tested config for that, since most prefer to optimise for their machines
anyway.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread hollunder 
On Thu, 24 Sep 2009 06:15:36 +0800
Ray Rashif  wrote:

> Indeed, sounds like Arch. And it's not a bad thing that you can't
> fall back to older versions if you keep the cache. I mean in this age
> of cheap storage, who wouldn't?
> 
> About the rt kernel, I don't think it'll ever be maintained in the
> official repos. But at the same time, a lot of good packages will not
> either. That is why we have the AUR, and third-party binary
> repositories. If you see faults or would like something added with
> regards to rt/kernel/audio packages, do chat with the archaudio guys.
> 
> But if you feel you have grown accustomed to Red Hat or Debian
> systems, then go for one of the other suggestions here. Arch has got
> a BSD-style init; 1 file for runlevel config (inittab), 1 file for
> global config (rc.conf), 1 dir for init scripts (rc.d), 1 dir for
> optional init scripts config (conf.d). As such, it's simpler to
> administer and maintain without having to go through a maze of
> symlinking.

Oh, yeah, this brings me to a point that I forgot to mention previously:
The package management tool, pacman, is really just that. It doesn't do
any system administration for you, you have to do that yourself.
This is mainly merging of config files and somesuch, it hasn't been a
lot of trouble for me so far.
For really big changes that affect many there's some advisory on the
website and on some ML, but that's it, so it's a good idea to check
that before doing updates.

About the rt kernels:
We don't have as much experience as Fernando, so the rt kernels
are probably not as tuned yet, but since it's trivial to make config
changes and compile/install kernels that could change quickly. The
current rt kernels are based on the vanilla kernels and unpatched
(except for some ATI graphics compatibility), which is a little plus I
guess.

Well, that's all I can think of for now.
Hope that helps,
Philipp
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Ray Rashif 
Indeed, sounds like Arch. And it's not a bad thing that you can't fall back
to older versions if you keep the cache. I mean in this age of cheap
storage, who wouldn't?

About the rt kernel, I don't think it'll ever be maintained in the official
repos. But at the same time, a lot of good packages will not either. That is
why we have the AUR, and third-party binary repositories. If you see faults
or would like something added with regards to rt/kernel/audio packages, do
chat with the archaudio guys.

But if you feel you have grown accustomed to Red Hat or Debian systems, then
go for one of the other suggestions here. Arch has got a BSD-style init; 1
file for runlevel config (inittab), 1 file for global config (rc.conf), 1
dir for init scripts (rc.d), 1 dir for optional init scripts config
(conf.d). As such, it's simpler to administer and maintain without having to
go through a maze of symlinking.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] ALSA latency and MMAP

2009-09-23 Thread Fons Adriaensen 
On Thu, Sep 24, 2009 at 12:16:45AM +0300, Jussi Laako wrote:

> Clemens Ladisch wrote:
> > To decrease that output buffering latency, make sure that there is less
> > valid data in the buffer when you are writing.  This is initially
> > determined by the amount of data you put into the buffer before starting
> > streaming, and can be later adjusted with snd_pcm_forward/rewind().
> 
> How it should work on ALSA as well as OSS for low latency:
> 
> 1) Set period size to something suitable
> 2) Set number of periods to 2
> 3) Write two periods of silence to output
> 3.5) Optionally trigger-start both input and output
> 4) Block on input until period available
> 5) Process the input
> 6) Write period to the output
> By this time, first of originally written periods has been played and
> second is playing, now the second half of the "double buffer" gets
> filled. Input buffer doesn't ever have more than one period.

More generally, 

2) Set number of periods to N (N >= 2)
3) Write N periods of silence to output.

This is exactly what Jack's backend and clalsadrv are
doing. Both use mmapped access, and also wait on both
the read and write fd's (this may be overkill if both
streams are sync-started). Both also have some extra
code do cleanly recover and restart after an xrun.

IIRC the OP wanted to use read/write access. If ALSA
allows to call read() so it block until a period is
available that would work, in that case you can probably
write() without waiting, as the output stream _should_
be ready to accept a period if both streams were started
together.

Round-trip latency is N periods, plus some extra for
the HW.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] ALSA latency and MMAP

2009-09-23 Thread Jussi Laako 
Clemens Ladisch wrote:
> To decrease that output buffering latency, make sure that there is less
> valid data in the buffer when you are writing.  This is initially
> determined by the amount of data you put into the buffer before starting
> streaming, and can be later adjusted with snd_pcm_forward/rewind().

How it should work on ALSA as well as OSS for low latency:

1) Set period size to something suitable
2) Set number of periods to 2
3) Write two periods of silence to output
3.5) Optionally trigger-start both input and output
4) Block on input until period available
5) Process the input
6) Write period to the output
By this time, first of originally written periods has been played and
second is playing, now the second half of the "double buffer" gets
filled. Input buffer doesn't ever have more than one period.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] clalsadrv - where is src?

2009-09-23 Thread Fons Adriaensen 
On Wed, Sep 23, 2009 at 10:36:25PM +0200, Guido Scholz wrote:

> there was also an outdated link on the AlsaModularSynth homepage

Probably pointing to my old skynet site which was removed two
years ago but still pops up every now and then...

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread hollunder 
On Wed, 23 Sep 2009 20:49:33 +0200
Fons Adriaensen  wrote:

> On Wed, Sep 23, 2009 at 07:30:27PM +0100, Chris Cannam wrote:
> 
> > On Wed, Sep 23, 2009 at 7:26 PM, Fons Adriaensen
> >  wrote:
> 
> > > So what distro should I go for ?
> > 
> > Sounds like Arch is worth a look.
> 
> Do they have a ready-to-use RT kernel ?
> 
> Ciao,
> 

There is a buildscript for one as well as a separate binary repository
including a binary rt kernel.
Currently it's already .31-rt that's being tested.
I do have consolekit here tough.

The beauty of Arch Linux is:
- Emphasis on simplicity, don't hide how stuff works, etc. see:
  http://wiki.archlinux.org/index.php/The_Arch_Way
- The base system is minimal
- Official binary repositories are available, including most popular
  applications
- Applications in the repositories are very recent versions due to a
  rolling release model
- Everything in the official repositories can be rebuilt easily,
  using the same scripts that were used to build the official package
  (ABS). Very useful if you want to have other compiletime options or do
  optimisations (everything is compiled for i686/x86_64 by default).
- Almost anything that's not in the official repositories can be found
  in a user maintained buildscript repository (AUR).
- There's a growing external buildscript/binary repository for audio
  applications (archaudio.org)

Sure there are drawbacks
- Arch patches as little as possible, there are no security updates
  unless upstream fixes it and provides a new version
- Rolling release model can break stuff
- very recent versions of software can break stuff

I hope I didn't forget anything important.
The arch wiki is an o.k. resource to get an overview and
general information, or just ask here or on an Arch Linux mailinglist.

Regards,
Philipp
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Raymond Martin 
On September 23, 2009 02:26:03 pm Fons Adriaensen wrote:
> Hello all,
> 
> A number of system here, including the ones at the Casa
> del Suono are to be upgraded in the coming weeks.
> 
> At the moment they all run Fedora 8, so the first choice
> would be to go for Fedora 11. But:
> 
> * None of them will run Gnome or KDE.
> * Most will be headless anyaway.
> * I want access/privilege control to be based on
>   user and group ID and nothing else. Privileges
>   will never depend on the user having a local
>   login or desktop session.
> * I'm prepared to have to spend some time configuring
>   udev, pam, /etc/fstab etc. etc. etc.
> * What I certainly *do not want* is some parallel
>   access control system that would interfere with
>   the above, or that could modify/bypass/enhance
>   in any way what has been configured there.
> * I'm *not* really prepared to have to waste any time
>   reconfiguring the Kit family. Consequently I don't
>   want to see any of them.
> 
> So what distro should I go for ? Having to spend weeks
> compiling everything from source is not an option.

If you look at the distro list at http://www.linux.org you can see
a number of potential candidates (Power User distros).

>From a first glance a few seem possible to me: Slackware, CERN linux, CentOS 
(RHEL-based), Scientific Linux (RHEL-based), 64 Studio, amongst others. Which 
of them has a stock rt kernel is a good question (which general/regular
distros have an easily accessible rt kernel?).

Good luck.

Raymond





___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] clalsadrv - where is src?

2009-09-23 Thread Fons Adriaensen 
On Wed, Sep 23, 2009 at 10:27:03PM +0200, Guido Scholz wrote:

> Hi James,
>  
> > can anyone tell me where clalsadrv is?
> 
> here:
> 
>   http://www.kokkinizita.net/linuxaudio/downloads/index.html

The clalsadrv lib is one of my first sins - it was originally
developed to clean up the ALSA device code in AMS, and later
also used in Jaaa, Japa, Aeolus, and some others. 

It provides a single C++ class that wraps the rather convolved
code required to initialise an ALSA device for mmapped access,
also doing the conversion from/to floats, and is similar to
Jack's ALSA backend on which it was originally based.

It makes the task of writing apps that both support Jack and
ALSA a bit easier, basically you have to create a RT thread
that just executes a loop calling methods provided by the library,
and the same audio processing function that would also be called
from your Jack process callback. If used in this way it provides
callback based access to ALSA.

It hasn't been maintained for some time, and I always use all
the apps that use it with Jack, so it may be in need of some
updates (for things like big-endian sample formats and such).
If it fails for your ALSA device just let me know, it can 
probably be fixed easily in that case.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] clalsadrv - where is src?

2009-09-23 Thread Guido Scholz 
Am Wed, 23. Sep 2009 um 21:05:38 +0100 schrieb james morris:

> Hi,

Hi James,
 
> can anyone tell me where clalsadrv is?

there was also an outdated link on the AlsaModularSynth homepage

  http://alsamodular.sourceforge.net/

in the "Download" section, which is updated right now.

Guido

-- 
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/


signature.asc
Description: Digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] clalsadrv - where is src?

2009-09-23 Thread Guido Scholz 
Am Wed, 23. Sep 2009 um 21:05:38 +0100 schrieb james morris:

> Hi,

Hi James,
 
> can anyone tell me where clalsadrv is?

here:

  http://www.kokkinizita.net/linuxaudio/downloads/index.html

Guido

-- 
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/


signature.asc
Description: Digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] clalsadrv - where is src?

2009-09-23 Thread james morris 

On 23/9/2009, "Karsten Wiese"  wrote:

>http://www.kokkinizita.net/linuxaudio/downloads/index.html
>

Thanks :-)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] clalsadrv - where is src?

2009-09-23 Thread Karsten Wiese 
http://www.kokkinizita.net/linuxaudio/downloads/index.html
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] clalsadrv - where is src?

2009-09-23 Thread james morris 

Hi,

I'm trying to build AMS, but ./configure can't find clalsadrv and I
can't find where to download the source for it. I've already built
from source:

alsa-driver-1.0.20
alsa-tools-1.0.20
alsa-plugins-1.0.20
alsa-lib-1.0.20

can anyone tell me where clalsadrv is?

Cheers,
James.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Ralf Mardorf 
Fons Adriaensen wrote:
> On Wed, Sep 23, 2009 at 07:30:27PM +0100, Chris Cannam wrote:
>
>   
>> On Wed, Sep 23, 2009 at 7:26 PM, Fons Adriaensen  
>> wrote:
>> 
>
>   
>>> So what distro should I go for ?
>>>   
>> Sounds like Arch is worth a look.
>> 
>
> Do they have a ready-to-use RT kernel ?
>
> Ciao,

I don't think so, 
http://wiki.archlinux.org/index.php/Kernel_Patches_and_Patchsets#-rt, 
but Arch and Sidux seems to be popular for people with similar needs as 
yours.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Guido Scholz 
Am Wed, 23. Sep 2009 um 20:26:03 +0200 schrieb Fons Adriaensen:

> Hello all,

Hi Fons,

> So what distro should I go for ? Having to spend weeks
> compiling everything from source is not an option.

what about CentOS 5 with the CCRMA extensions:



CentOS is not that type of rapidly moving target like Fedora but with
equal administration tools. This would also honor Fernandos efforts.

> Anyone able to point in the right direction will receive
> my eternal gratitude which could be expressed in quantities
> of fine Italian food and drinks if the occasion arises.

Sounds attractive, Parma is not too far away.

Guido

-- 
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/


signature.asc
Description: Digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Fons Adriaensen 
On Wed, Sep 23, 2009 at 07:30:27PM +0100, Chris Cannam wrote:

> On Wed, Sep 23, 2009 at 7:26 PM, Fons Adriaensen  wrote:

> > So what distro should I go for ?
> 
> Sounds like Arch is worth a look.

Do they have a ready-to-use RT kernel ?

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Chris Cannam 
On Wed, Sep 23, 2009 at 7:26 PM, Fons Adriaensen  wrote:
> So what distro should I go for ?

Sounds like Arch is worth a look.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[LAD] (Somewhat OT) Advice needed on distro choice

2009-09-23 Thread Fons Adriaensen 
Hello all,

A number of system here, including the ones at the Casa
del Suono are to be upgraded in the coming weeks. 

At the moment they all run Fedora 8, so the first choice
would be to go for Fedora 11. But:

* None of them will run Gnome or KDE.
* Most will be headless anyaway.
* I want access/privilege control to be based on
  user and group ID and nothing else. Privileges
  will never depend on the user having a local
  login or desktop session.
* I'm prepared to have to spend some time configuring
  udev, pam, /etc/fstab etc. etc. etc. 
* What I certainly *do not want* is some parallel
  access control system that would interfere with
  the above, or that could modify/bypass/enhance
  in any way what has been configured there.
* I'm *not* really prepared to have to waste any time
  reconfiguring the Kit family. Consequently I don't
  want to see any of them.

So what distro should I go for ? Having to spend weeks
compiling everything from source is not an option.

Anyone able to point in the right direction will receive
my eternal gratitude which could be expressed in quantities
of fine Italian food and drinks if the occasion arises.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Pd, Csound and SuperCollider code as plugin

2009-09-23 Thread Stefano D'Angelo 
2009/9/23 Victor Lazzarini :
> Well, there is a LADSPA plugin generator that uses Csound. I suppose it
> can serve the basis for a LV2 version, if anyone has the time to write it...

IIRC, CSound can be embedded in another application, so maybe it makes
sense to write a "regular" automagical CSound->LV2 bridge (Disclaimer:
I've never used CSound myself, so what I'm saying may very well make
no sense at all).

Stefano

> Victor
>
> On 22 Sep 2009, at 11:36, Stefano D'Angelo wrote:
>
>> 2009/9/22 rosea grammostola :
>>>
>>> victor wrote:

 I suppose by virtue of Jack, it's possible to run SC, PD, Csound or
 anything
 jackable as a separate process, and pretend it is a plugin to things
 like
 Ardour.
>>>
>>> Of course that is possible, and a fine thing. But some people wants to
>>> make music, not instruments...
>>> Of course it's better if you learn the whole language, but not everyone
>>> wants that, have the time or capacity for it.
>>>
>>> So such a plugin interface should make it more easy for just musicians
>>> to make use of the intstruments and effects in Pd, Csound or SC.
>>>
>>> I also  can imagine such a thing would be good for projects like Ardour.
>>> For some people the lack of commercial VST plugins is a reason not to
>>> use Linux. You may fill that gap by having some pretty cool and easy to
>>> use SC or Pd plugins.
>>
>> If anybody wants to bridge any of these languages/environments to LV2,
>> please tell me.
>>
>>> Regards,
>>>
>>> \r
>>> ___
>>> Linux-audio-dev mailing list
>>> Linux-audio-dev@lists.linuxaudio.org
>>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>>
>> ___
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Pd, Csound and SuperCollider code as plugin

2009-09-23 Thread Victor Lazzarini 
Well, there is a LADSPA plugin generator that uses Csound. I suppose it
can serve the basis for a LV2 version, if anyone has the time to write  
it...

Victor

On 22 Sep 2009, at 11:36, Stefano D'Angelo wrote:

> 2009/9/22 rosea grammostola :
>> victor wrote:
>>> I suppose by virtue of Jack, it's possible to run SC, PD, Csound  
>>> or anything
>>> jackable as a separate process, and pretend it is a plugin to  
>>> things like
>>> Ardour.
>> Of course that is possible, and a fine thing. But some people wants  
>> to
>> make music, not instruments...
>> Of course it's better if you learn the whole language, but not  
>> everyone
>> wants that, have the time or capacity for it.
>>
>> So such a plugin interface should make it more easy for just  
>> musicians
>> to make use of the intstruments and effects in Pd, Csound or SC.
>>
>> I also  can imagine such a thing would be good for projects like  
>> Ardour.
>> For some people the lack of commercial VST plugins is a reason not to
>> use Linux. You may fill that gap by having some pretty cool and  
>> easy to
>> use SC or Pd plugins.
>
> If anybody wants to bridge any of these languages/environments to LV2,
> please tell me.
>
>> Regards,
>>
>> \r
>> ___
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] ALSA latency and MMAP

2009-09-23 Thread Clemens Ladisch 
Louis Gorenfeld wrote:
> on 1) When you say the output buffer is full, it is full of flatline
> (dc/blank/etc), right?

This doesn't matter for the algorithm since I'm only interested in the
latency between recording some data and actually playing _that_ data.
In my example program, that data is silence so that I can detect the
signal.

> on 2) At this point, the input data is read and is in the first period
> (that is, it's not visible to the program yet)?

The input data was just read, that is, it was recorded in the time
since the last readi() (or since the pcm_start).

> on 3) At this point, the input data is visible to the software and
> immediately copied to the first output period, right?  I don't
> understand why the output buffer is still partially full.

Because the read did not block.

> Are you saying that the input and output period boundaries don't
> necessarily line up?

This can happen with certain devices, but usually not with PCI sound
cards.

>> In the recorded data, there is a silent gap of two periods between each
>> two periods containing data; this is the same behaviour that you see.
> 
> I'm not hearing any audible gapping.. is this what you mean?

It's only a few milliseconds anyway.

>> To reduce the latency, you would have to keep the output buffer more
>> empty.  In my test program, try removing one of the writei calls before
>> the snd_pcm_start.
> 
> But since the input and output are synched and in my solution not
> blocking on input, wouldn't adding writei just cause a buffer overrun
> in the input while it writes out blank buffers?

Yes, but I wrote "removing".

> I'm not clear on how this actually adds latency.  I was under the
> impression that was a function of buffer size.

This depends on how you manage the output buffer.

There are several latencies that add to the overall latency of the
program.

DMA FIFOs and group delays of the input/output devices are fixed.

The input buffering has a fixed latency of one period, because you can
structure the algorithm so that the input data is read as soon as a
period has been recorded.  (The input buffer size does not matter, so
you can make it as big as possible to prevent overruns.)

The output buffering latency is the time between writing some data to
the buffer and the actual playback of that data, and that interval is
equivalent to the amount of data that is already in the buffer when you
are writing.  If the buffer is already completely filled, the entire
buffer must be played before your new data, so the entire buffer length
determines the latency.

With a two-period buffer, the input and output buffering latencies add
up to three periods, which is what you are observing in your program.

To decrease that output buffering latency, make sure that there is less
valid data in the buffer when you are writing.  This is initially
determined by the amount of data you put into the buffer before starting
streaming, and can be later adjusted with snd_pcm_forward/rewind().

So, how much data does your program write into the output buffer before
calling snd_pcm_start(), and how exactly does your program determine if
it should call snd_pcm_forward() on the output buffer?


Best regards,
Clemens
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev