Documentation for sample rates

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Documentation for sample rates

Ryan Heise
I couldn't find it :-)

What exactly causes these error messages to occur?

1. "playback and capture sample rates do not match"
2. "sample rate in use does not match requested rate"

How do we configure jack to stop the crackling noise? (If compiling the
CVS version still does not do the trick?)

***

Here are my attempts to pipe a 44100 audiofile through jack:

$ /usr/bin/jackd -R -d alsa -d hw:0 -r 44100 -p 1024 -n 2

Gives error: playback and capture sample rates do not match (48000 vs.
44100)

And a whole heap of xruns. Now:

$ alsaplayer -o jack somefile

plays the music about 1 whole tone higher, with frequent and periodic
gaps in the sound to slow it down to normal speed.

On the other hand:

$ /usr/bin/jackd -R -d alsa -d hw:0 -r 48000 -p 1024 -n 2

No errors.

But when I pipe the 44100 audiofile:

$ alsaplayer -o jack somefile
jack: running interface at 48000 instead of 44100

It runs at the correct pitch and speed, but the sound quality is
extremely poor.

If I kill jack, and run:

$ alsaplayer -o alsa somefile

There are no errors, and the sound quality is perfect.


Surely if alsaplayer can talk to alsa properly, jack can do it too?

Looking at the alsaplayer source, it does this:

    val = output_rate; /* 44100 */
    err = snd_pcm_hw_params_set_rate_near(sound_handle, hwparams,
                                     &val, 0);
    if (err < 0) {
        /* Try 48KHZ too */
        printf("%d HZ not available, trying 48000 HZ\n", output_rate);
        val = 48000;
        err = snd_pcm_hw_params_set_rate_near(sound_handle, hwparams,
                &val, 0);

Looking at jack source, I can't figure out what it does :-) But it looks
like it is not even attempting to call snd_pcm_hw_params_set_rate_near
with 44100, even though it appears from alsaplayer that it would indeed
work.

Can anyone help?

Thanks :-)

Btw, my sound card is:

0000:00:1b.0 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
High Definition Audio Controller (rev 04)

And I use the snd-hda-intel driver in ALSA 1.0.9, with Linux 2.6.11
(Debian)

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Paul Davis
> 1. "playback and capture sample rates do not match"

this is caused by h/w where, after requesting an SR of N for both
playback and capture, we check to see what we actually got, and it turns
out that one or both of the playback and capture rates != N.

> 2. "sample rate in use does not match requested rate"

there is a lot of consumer h/w these days that supports only a single
SR. i have a builtin chipset in my laptop, for example, that only
supports 48kHz. if you start up JACK asking to use 44.1kHz, it will
end up with a 48kHz rate, and this is (no longer) considered an error:
instead a warning message like the one you're quoting is printed to
stdout.

> How do we configure jack to stop the crackling noise? (If compiling the
> CVS version still does not do the trick?)

it has very very little to do with JACK. if its the crackling noise i am
thinking of, its caused by SR conversion either within ALSA, or within a
sound file playback program. this is assuming that JACK is not getting
xruns.

> Here are my attempts to pipe a 44100 audiofile through jack:
>
> $ /usr/bin/jackd -R -d alsa -d hw:0 -r 44100 -p 1024 -n 2
>
> Gives error: playback and capture sample rates do not match (48000 vs.
> 44100)

yep, you've got nasty consumer hardware. if you only want to do
playback, add -P to the flags and JACK will not bother with
opening the device for capture.

> And a whole heap of xruns. Now:

this is a system-level issue. you cannot run with 1024 frames per
period, and only 2 periods (-p 1024 -n 2) without a fairly well
configured system. what distro are you using, what kernel, what
filesystem, what video card etc etc etc.

> $ alsaplayer -o jack somefile
>
> plays the music about 1 whole tone higher, with frequent and periodic
> gaps in the sound to slow it down to normal speed.

of course, because the actual SR of the h/w is different than the
soundfile. this type of consumer h/w expects software to do sample rate
conversion on its behalf.

> On the other hand:
>
> $ /usr/bin/jackd -R -d alsa -d hw:0 -r 48000 -p 1024 -n 2
>
> No errors.

right, because you've asked to use the only SR that the h/w supports.

> But when I pipe the 44100 audiofile:
>
> $ alsaplayer -o jack somefile
> jack: running interface at 48000 instead of 44100
>
> It runs at the correct pitch and speed, but the sound quality is
> extremely poor.

because alsaplayer's sample rate conversion code is not very good.

> If I kill jack, and run:
>
> $ alsaplayer -o alsa somefile
>
> There are no errors, and the sound quality is perfect.

because it opens the plughw:0 device (which is the default audio device
for all ALSA programs), which in effect gets ALSA, not alsaplayer, to
handle sample rate conversion at some small cost in efficiency. the
plughw:0 device is not limited to SR's supported by the hardware (ditto
for sample formats, interleave format, channel count and more).

> Surely if alsaplayer can talk to alsa properly, jack can do it too?

  jackd -d alsa -d plughw:0 -r whatever_rate_you_want .....

i don't recommend it, but it will work for you. this switch to single,
fixed SR h/w is really terrible, but hey, its what more and more people
have to put up with. almost as bad as winmodems, actually.

> Looking at jack source, I can't figure out what it does :-) But it looks
> like it is not even attempting to call snd_pcm_hw_params_set_rate_near
> with 44100, even though it appears from alsaplayer that it would indeed
> work.

jack/drivers/alsa/alsa_driver.c:413

> 0000:00:1b.0 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
> High Definition Audio Controller (rev 04)

"High Definition" .... bwahahaha :)

--p





-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Alfons Adriaensen
On Mon, Jul 25, 2005 at 09:40:39AM -0400, Paul Davis wrote:

> i don't recommend it, but it will work for you. this switch to single,
> fixed SR h/w is really terrible, but hey, its what more and more people
> have to put up with. almost as bad as winmodems, actually.

Is this really so bad ? If you consider the following two
requirements for an audio interface:

1. it should support a number of clients at the same time,
2. the HW should adapt to the sample rate of a client,

they are in fact contradictory, unless your card support HW
mixing at different samplerates and I suspect very few do.

In other words, once you take multiple clients for granted,
SW resampling follows logically and having fixed rate HW
should not be an issue.

--
FA
 












-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Paul Davis
On Mon, 2005-07-25 at 16:41 +0200, Alfons Adriaensen wrote:
> In other words, once you take multiple clients for granted,
> SW resampling follows logically and having fixed rate HW
> should not be an issue.

that would be great if they actually supported multiple clients as well.
instead this increasingly seems to be offloaded to the OS just like
SR conversion.




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Ryan Heise
In reply to this post by Paul Davis
Hi Paul, thanks for your very detailed response!

On Mon, Jul 25, 2005 at 09:40:39AM -0400, Paul Davis wrote:
>   jackd -d alsa -d plughw:0 -r whatever_rate_you_want .....

Ok, I tried this (back with 0.99.0):


$ /usr/bin/jackd -R -d alsa -d plughw:0 -r 44100 -p 1024 -n 2 -P
jackd 0.99.0
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

loading driver ..
apparent rate = 44100
creating alsa driver ...
plughw:0|-|1024|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 1024 frames, buffer = 2 periods
You appear to be using the ALSA software "plug" layer, probably
a result of using the "default" ALSA device. This is less
efficient than it could be. Consider using a hardware device
instead rather than using the plug layer. Usually the name of the
hardware device that corresponds to the first soun
ALSA: cannot set period size to 1024 frames for playback
ALSA: cannot configure playback channel
cannot load driver module alsa


I tried different sized frames other than 1024, but it still gives this
error message.

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Lee Revell
In reply to this post by Paul Davis
On Mon, 2005-07-25 at 10:51 -0400, Paul Davis wrote:
> On Mon, 2005-07-25 at 16:41 +0200, Alfons Adriaensen wrote:
> > In other words, once you take multiple clients for granted,
> > SW resampling follows logically and having fixed rate HW
> > should not be an issue.
>
> that would be great if they actually supported multiple clients as well.
> instead this increasingly seems to be offloaded to the OS just like
> SR conversion.

That's the Windows world for you.  Anything that can theoretically be
offloaded to software thus saving $0.0001 per unit, will eventually be
pushed into the OS.

Half the time they still advertise it as a hardware feature, apparently
their reasoning is that anything that lives in the driver "looks like" a
hardware feature so that's what it is.

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Ryan Heise
In reply to this post by Ryan Heise
I am trying to figure out this error:

On Tue, Jul 26, 2005 at 01:05:59AM +1000, Ryan Heise wrote:
> $ /usr/bin/jackd -R -d alsa -d plughw:0 -r 44100 -p 1024 -n 2 -P
> ALSA: cannot set period size to 1024 frames for playback
> ALSA: cannot configure playback channel

It seems alsaplayer also sets the period size to 1024 (by default), yet
it does not give this error. There must be something different that
alsaplayer and jackd are doing that is causing the error in jackd and
not alsaplayer, but I have no idea what it is.

Any suggestions? Anyway to trace snd_* calls to see what's going on?

Thanks,

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Lee Revell
On Tue, 2005-07-26 at 10:36 +1000, Ryan Heise wrote:

> I am trying to figure out this error:
>
> On Tue, Jul 26, 2005 at 01:05:59AM +1000, Ryan Heise wrote:
> > $ /usr/bin/jackd -R -d alsa -d plughw:0 -r 44100 -p 1024 -n 2 -P
> > ALSA: cannot set period size to 1024 frames for playback
> > ALSA: cannot configure playback channel
>
> It seems alsaplayer also sets the period size to 1024 (by default), yet
> it does not give this error. There must be something different that
> alsaplayer and jackd are doing that is causing the error in jackd and
> not alsaplayer, but I have no idea what it is.
>

alsaplayer accepts whatever period size ALSA gives it, while JACK bails
if the actual period size does not match the requested period size.

> Any suggestions? Anyway to trace snd_* calls to see what's going on?

Look at the source and/or run it under gdb?

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Ryan Heise
On Mon, Jul 25, 2005 at 08:45:44PM -0400, Lee Revell wrote:
> alsaplayer accepts whatever period size ALSA gives it, while JACK bails
> if the actual period size does not match the requested period size.

The alsaplayer source code has:

    periodsize = (*fragment_size) / 4; /* bytes -> frames for 16-bit,stereo */
    err = snd_pcm_hw_params_set_period_size_near(sound_handle, hwparams,
                                            &periodsize, 0);
    if (err < 0) {
        printf("error on set_period_size (%d)\n", (int)periodsize);
        goto _err;
    }

But when I run:

$ alsaplayer -f 4096 -o alsa mysoundfile

the above error message is not displayed.

Doesn't this mean that snd_pcm_hw_params_set_period_size_near is
succeeding to set the period size to 1024 in alsaplayer, but not in
jackd?

Thanks,

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Paul Davis
On Tue, 2005-07-26 at 11:21 +1000, Ryan Heise wrote:

> On Mon, Jul 25, 2005 at 08:45:44PM -0400, Lee Revell wrote:
> > alsaplayer accepts whatever period size ALSA gives it, while JACK bails
> > if the actual period size does not match the requested period size.
>
> The alsaplayer source code has:
>
>     periodsize = (*fragment_size) / 4; /* bytes -> frames for 16-bit,stereo */
>     err = snd_pcm_hw_params_set_period_size_near(sound_handle, hwparams,
>                                             &periodsize, 0);
>     if (err < 0) {
>         printf("error on set_period_size (%d)\n", (int)periodsize);
>         goto _err;
>     }
>
> But when I run:
>
> $ alsaplayer -f 4096 -o alsa mysoundfile
>
> the above error message is not displayed.
>
> Doesn't this mean that snd_pcm_hw_params_set_period_size_near is
> succeeding to set the period size to 1024 in alsaplayer, but not in
> jackd?

no, it means that alsaplayer uses the "near" variant, while the ALSA
backend for jack uses the "exact" variant. hence, alsaplayer is
tolerant, jackd is not. whether this is a virtue or not is up to you to
decide - people can reasonably disagree about which behaviour makes more
sense.

in addition, alsaplayer probably requests more periods at the same
period size. try jackd -d alsa ... -n 4 or -n 3

--p




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Ryan Heise
On Mon, Jul 25, 2005 at 10:07:56PM -0400, Paul Davis wrote:
> no, it means that alsaplayer uses the "near" variant, while the ALSA
> backend for jack uses the "exact" variant. hence, alsaplayer is
> tolerant, jackd is not. whether this is a virtue or not is up to you to
> decide - people can reasonably disagree about which behaviour makes more
> sense.
>
> in addition, alsaplayer probably requests more periods at the same
> period size. try jackd -d alsa ... -n 4 or -n 3

I tried -n 1 .. up to -n 6 with no luck.

Is there a way to probe the system to see what values it expects?

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Ryan Heise
On Tue, Jul 26, 2005 at 12:17:58PM +1000, Ryan Heise wrote:
> Is there a way to probe the system to see what values it expects?

Or, do you think there might be a bug in the alsa driver?

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Paul Davis
In reply to this post by Ryan Heise
On Tue, 2005-07-26 at 12:17 +1000, Ryan Heise wrote:

> On Mon, Jul 25, 2005 at 10:07:56PM -0400, Paul Davis wrote:
> > no, it means that alsaplayer uses the "near" variant, while the ALSA
> > backend for jack uses the "exact" variant. hence, alsaplayer is
> > tolerant, jackd is not. whether this is a virtue or not is up to you to
> > decide - people can reasonably disagree about which behaviour makes more
> > sense.
> >
> > in addition, alsaplayer probably requests more periods at the same
> > period size. try jackd -d alsa ... -n 4 or -n 3
>
> I tried -n 1 .. up to -n 6 with no luck.
>
> Is there a way to probe the system to see what values it expects?

use alsaplayer, and then:

  cat /proc/asound/cardN/pcm0p/sub0/*
  cat /proc/asound/cardN/pcm0c/sub0/*

replacing N with an appropriately small valued integer, typically 0 or
1.

--p



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Lee Revell
In reply to this post by Ryan Heise
On Tue, 2005-07-26 at 12:25 +1000, Ryan Heise wrote:
> On Tue, Jul 26, 2005 at 12:17:58PM +1000, Ryan Heise wrote:
> > Is there a way to probe the system to see what values it expects?
>
> Or, do you think there might be a bug in the alsa driver?

Since you have bleeding edge hardware, this is a distinct possibility.

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Ryan Heise
In reply to this post by Paul Davis
On Mon, Jul 25, 2005 at 10:31:08PM -0400, Paul Davis wrote:
> use alsaplayer, and then:
>
>   cat /proc/asound/cardN/pcm0p/sub0/*
>   cat /proc/asound/cardN/pcm0c/sub0/*
>
> replacing N with an appropriately small valued integer, typically 0 or
> 1.

$ ls /proc/asound
Intel    card0  cards    hwdep    oss  seq     version
VirMIDI  card1  devices  modules  pcm  timers
$ cat /proc/asound/card0/pcm0p/sub0/*
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384
tick_time: 1000
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: CMI9880
name: CMI9880
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
64
state: RUNNING
trigger_time: 1122345170.440734000
tstamp      : 1122345289.792284000
delay       : -5729672
avail       : 5746056
avail_max   : 5746056
-----
hw_ptr      : 5729672
appl_ptr    : 0
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 1024
xfer_align: 1024
start_threshold: 1
stop_threshold: 1073741824
silence_threshold: 0
silence_size: 1073741824
boundary: 1073741824
$ cat /proc/asound/card0/pcm0c/sub0/*
closed
card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: CMI9880
name: CMI9880
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 2
subdevices_avail: 2
64
closed
closed

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Lee Revell
On Tue, 2005-07-26 at 12:39 +1000, Ryan Heise wrote:

> On Mon, Jul 25, 2005 at 10:31:08PM -0400, Paul Davis wrote:
> > use alsaplayer, and then:
> >
> >   cat /proc/asound/cardN/pcm0p/sub0/*
> >   cat /proc/asound/cardN/pcm0c/sub0/*
> >
> > replacing N with an appropriately small valued integer, typically 0 or
> > 1.
>
> period_size: 1024
> buffer_size: 16384

alsaplayer is using 16 periods per buffer.  JACK uses two by default.

Try jack with -n 2 through -n 16 and see which ones work.

I still think it's a driver bug.  The period/buffer size table in the
driver is supposed to encode the hardware constraints but more often
than not the values used are just someone's guess.  We can try setting
it lower.

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Glynn Clements
In reply to this post by Paul Davis

Paul Davis wrote:

> > $ alsaplayer -o jack somefile
> > jack: running interface at 48000 instead of 44100
> >
> > It runs at the correct pitch and speed, but the sound quality is
> > extremely poor.
>
> because alsaplayer's sample rate conversion code is not very good.

Hmm. My h/w (ens1371) only runs at 48000, and I can't tell the
difference between 44100 and 48000 sound files through alsaplayer &
JACK.

By "extremely poor", are you talking about something which would be
obvious even to someone used to listening to 128Kbps MP3s on crappy PC
speakers, or "not as good as my Technics/NAD/whatever"?

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Lee Revell
In reply to this post by Lee Revell
On Mon, 2005-07-25 at 22:43 -0400, Lee Revell wrote:
> I still think it's a driver bug.  The period/buffer size table in the
> driver is supposed to encode the hardware constraints but more often
> than not the values used are just someone's guess.  We can try setting
> it lower.

The driver looks fine (it should take a period size as small as 128
bytes, 32 frames at S16LE).  So your problem is somewhere else.

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Ryan Heise
In reply to this post by Ryan Heise
On Tue, Jul 26, 2005 at 12:17:58PM +1000, Ryan Heise wrote:
> > in addition, alsaplayer probably requests more periods at the same
> > period size. try jackd -d alsa ... -n 4 or -n 3
>
> I tried -n 1 .. up to -n 6 with no luck.

It seems the source of the problem will not be fixed any time soon:

http://www.mail-archive.com/alsa-devel@.../msg03428.html

Therefore, I propose the following workaround for jackd. It should
behave the way you intended your code to work, but avoids the buggy
implementation of snd_pcm_hw_params_set_period_size.

Instead of using snd_pcm_hw_params_set_period_size, use
snd_pcm_hw_params_set_period_size_near, but give an error if you don't
get what you requested. This succeeds in valid cases where the other
approach fails (amazingly enough).

I inserted some printf calls into alsaplayer to see what period size it
requests and gets:

requested periodsize (1024)
got periodsize (940)

If I actually request that, I get:

requested periodsize (940)
got periodsize (940)

But if I run jack with a period size of 940 (and the same number of
channels as with alsaplayer), it fails to set that period size. So,
snd_pcm_hw_params_set_period_size_near can probably be used instead of
snd_pcm_hw_params_set_period_size to the effect that you want, and work
in more cases.

Ryan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Documentation for sample rates

Paul Davis
> Therefore, I propose the following workaround for jackd. It should
> behave the way you intended your code to work, but avoids the buggy
> implementation of snd_pcm_hw_params_set_period_size.
>
> Instead of using snd_pcm_hw_params_set_period_size, use
> snd_pcm_hw_params_set_period_size_near, but give an error if you don't
> get what you requested. This succeeds in valid cases where the other
> approach fails (amazingly enough).

probably not a bad idea.




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
12