CVS commit [0.99.11] ALSA playback latency patch

CVS commit [0.99.11] ALSA playback latency patch

[Jack O'Quin]

  * applied Takashi's ALSA driver patch (thanks!)

  * --nperiods now sets playback latency, not buffer size

  * man page update...

       -n, --nperiods int
              Specify  the number of periods of playback latency.
              In seconds, this corresponds  to  --nperiods  times
              --period  divided by --rate.  The default is 2, the
              minimum allowable.  For most devices, there  is  no
              need  for  any  other  value  with  the  --realtime
              option.  Without realtime privileges or with boards
              providing  unreliable  interrupts  (like ymfpci), a
              larger value may yield fewer xruns.  This can  also
              help  if the system is not tuned for reliable real­
              time scheduling.

              For most ALSA  devices,  the  hardware  buffer  has
              exactly  --period  times  --nperiods  frames.  Some
              devices demand a larger buffer.  If so,  JACK  will
              use  the  smallest  possible  buffer  containing at
              least --nperiods, but the playback latency does not
              increase.

Would someone with an RME32/96 card please test this version and
report your results.  You should now be able to run with --nperiods=2,
which did not work before due to the card's fixed buffer size (IIUC).
-- 
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: CVS commit [0.99.11] ALSA playback latency patch

[Jack O'Quin]

I should have made it clear that this is a JACK update, not ALSA.  :-)

"Jack O'Quin" <joq@io.com> writes:

>   * applied Takashi's ALSA driver patch (thanks!)
> 
>   * --nperiods now sets playback latency, not buffer size
> 
>   * man page update...
> 
>        -n, --nperiods int
>               Specify  the number of periods of playback latency.
>               In seconds, this corresponds  to  --nperiods  times
>               --period  divided by --rate.  The default is 2, the
>               minimum allowable.  For most devices, there  is  no
>               need  for  any  other  value  with  the  --realtime
>               option.  Without realtime privileges or with boards
>               providing  unreliable  interrupts  (like ymfpci), a
>               larger value may yield fewer xruns.  This can  also
>               help  if the system is not tuned for reliable real­
>               time scheduling.
> 
>               For most ALSA  devices,  the  hardware  buffer  has
>               exactly  --period  times  --nperiods  frames.  Some
>               devices demand a larger buffer.  If so,  JACK  will
>               use  the  smallest  possible  buffer  containing at
>               least --nperiods, but the playback latency does not
>               increase.
> 
> Would someone with an RME32/96 card please test this version and
> report your results.  You should now be able to run with --nperiods=2,
> which did not work before due to the card's fixed buffer size (IIUC).
> -- 
>   joq
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 

-- 
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: CVS commit [0.99.11] ALSA playback latency patch

[Florian Schmidt]

On 17 Nov 2004 23:09:24 -0600
"Jack O'Quin" <joq@io.com> wrote:

> 
> I should have made it clear that this is a JACK update, not ALSA.  :-)

Frankly i must say, that i do not quite understand what this patch changes.

from jackd 0.99:

        -p, --period    Frames per period (default: 1024)
        -n, --nperiods  Number of periods in hardware buffer (default: 2)

--nperiods never set the buffer size. This was always done by --period. Care
to elaborate? I have the feeling i must be blindstruck. Also i think the
0.99 behaviour is perfectly allright.

flo


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: CVS commit [0.99.11] ALSA playback latency patch

[Florian Schmidt]

On Thu, 18 Nov 2004 14:36:00 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> On 17 Nov 2004 23:09:24 -0600
> "Jack O'Quin" <joq@io.com> wrote:
> 
> > 
> > I should have made it clear that this is a JACK update, not ALSA.  :-)
> 
> Frankly i must say, that i do not quite understand what this patch changes.
> 
> from jackd 0.99:
> 
>         -p, --period    Frames per period (default: 1024)
>         -n, --nperiods  Number of periods in hardware buffer (default: 2)
> 
> --nperiods never set the buffer size. This was always done by --period. Care
> to elaborate? I have the feeling i must be blindstruck. Also i think the
> 0.99 behaviour is perfectly allright.

arr, well i think i got it now. You are talking about the _total_ buffer
size, right? Up to now it was determined by --nperiods * --periods. But
since some soundcards don't support these exact buffer sizes, you changed it
so that the total buffer size is big enough that --nperiods * --periods fits
into it, right?

flo


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: [Alsa-devel] CVS commit [0.99.11] ALSA playback latency patch

[Jack O'Quin]

Florian Schmidt <mista.tapas@gmx.net> writes:

> On Thu, 18 Nov 2004 14:36:00 +0100
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > On 17 Nov 2004 23:09:24 -0600
> > "Jack O'Quin" <joq@io.com> wrote:
> > 
> > > 
> > > I should have made it clear that this is a JACK update, not ALSA.  :-)
> > 
> > Frankly i must say, that i do not quite understand what this patch changes.
> > 
> > from jackd 0.99:
> > 
> >         -p, --period    Frames per period (default: 1024)
> >         -n, --nperiods  Number of periods in hardware buffer (default: 2)
> > 
> > --nperiods never set the buffer size. This was always done by --period. Care
> > to elaborate? I have the feeling i must be blindstruck. Also i think the
> > 0.99 behaviour is perfectly allright.
> 
> arr, well i think i got it now. You are talking about the _total_ buffer
> size, right? Up to now it was determined by --nperiods * --periods. But
> since some soundcards don't support these exact buffer sizes, you changed it
> so that the total buffer size is big enough that --nperiods * --periods fits
> into it, right?

Right.  

I forgot to update the --help text.  It should now say "Number of
periods of playback latency".  Will fix soon.
-- 
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: CVS commit [0.99.11] ALSA playback latency patch

[Takashi Iwai]

At Thu, 18 Nov 2004 14:52:04 +0100,
Florian Schmidt wrote:
> 
> On Thu, 18 Nov 2004 14:36:00 +0100
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > On 17 Nov 2004 23:09:24 -0600
> > "Jack O'Quin" <joq@io.com> wrote:
> > 
> > > 
> > > I should have made it clear that this is a JACK update, not ALSA.  :-)
> > 
> > Frankly i must say, that i do not quite understand what this patch changes.
> > 
> > from jackd 0.99:
> > 
> >         -p, --period    Frames per period (default: 1024)
> >         -n, --nperiods  Number of periods in hardware buffer (default: 2)
> > 
> > --nperiods never set the buffer size. This was always done by --period. Care
> > to elaborate? I have the feeling i must be blindstruck. Also i think the
> > 0.99 behaviour is perfectly allright.
> 
> arr, well i think i got it now. You are talking about the _total_ buffer
> size, right? Up to now it was determined by --nperiods * --periods. But
> since some soundcards don't support these exact buffer sizes, you changed it
> so that the total buffer size is big enough that --nperiods * --periods fits
> into it, right?

It's a kind of workaround for the cards which have the fixed buffer
size, or the period_min > 2.  On these cards, you have to set up
nperiods > 2 eventually.  But, by tuning avail_min properly, you can
still get the minimal playback latecy (= 2 * period_size).

As long as the board supports the requested buffer size, the behavior
is as exactly same as JACK 0.99.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8