From: James Courtier-Dutton <James@superbug.demon.co.uk>
To: Jaroslav Kysela <perex@suse.cz>
Cc: alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: Problem with buffer/period sizes.
Date: Sun, 12 Oct 2003 14:37:58 +0100 [thread overview]
Message-ID: <3F895936.8000707@superbug.demon.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.53.0310121049320.6682@pnote.perex-int.cz>
Jaroslav Kysela wrote:
> On Sat, 11 Oct 2003, James Courtier-Dutton wrote:
>
>
>>I have code that looks like the following: -
>>
>>err = snd_pcm_hw_params_get_buffer_size_min(params, &buffer_size_min);
>>err = snd_pcm_hw_params_get_buffer_size_max(params, &buffer_size_max);
>>dir=0;
>>err = snd_pcm_hw_params_get_period_size_min(params, &period_size_min,&dir);
>>dir=0;
>>err = snd_pcm_hw_params_get_period_size_max(params, &period_size_max,&dir);
>>
>><snip> some calculations happen here
>>
>>err = snd_pcm_hw_params_set_buffer_size_near(audio_fd, params,
>>&buffer_size);
>>dir=0;
>>err = snd_pcm_hw_params_set_period_size_near(audio_fd, params,
>>&period_size, &dir);
>>
>>For a snd_intel8x0 driver with INTEL ICH5 chip with
>>PCI IDs of 0x8086, 0x24d5
>>Displays: -
>>buffer_size_min/max = 64 / 16384
>>period_size_min/max = 16 / 16384
>>
>>We then try to set: -
>>buffer_size = 16384
>>period_size = 2048
>>And it accepts those settings, and works.
>>
>>For a snd_intel8x0 driver with NVIDIA NFORCE chip with
>>PCI IDs of 0x10de, 0x01b1
>>Displays: -
>>buffer_size_min/max = 67 / 15052
>>period_size_min/max = 7 / 15053
>>
>>We then try to set: -
>>buffer_size = 15048
>>period_size = 1881
>>But, this sets a period size = buffer_size = 15048 which then fails to
>>work due to not having 2 periods or more.
>>
>>What is causing the NFORCE chip to suggest such strange values, and then
>>to not accept those values.
>
>
> It appears that the NFORCE chip is clocked with 44.1kHz. Thus alsa-lib is
> trying to do the resampling from 44.1kHz to 48kHz. Unfortunately, we're
> fighting with some rounding errors so that we cannot guarantee that all
> hw parameter combinations will work.
>
> Because this situation is quite common for cheap motherboards where the
> hardware engineers are so clever to spare one clock crystal thus make the
> audio chips work with absolutely non-standard frequencies, I suggest to
> find a working combination of values and use it as last resort.
>
> Note that we will solve these hardware dependand things with the new
> "ordinary" PCM. We will guarantee that you'll have always working
> setup for given hardware there.
>
> Jaroslav
>
Thanks. In the mean time, I found a solution be reversing the order in
which I set period and buffer sizes, setting period size first, as
suggested by yourselves in previous mailing list items.
Cheers
James
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
prev parent reply other threads:[~2003-10-12 13:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-11 16:03 Problem with buffer/period sizes James Courtier-Dutton
2003-10-12 9:04 ` Jaroslav Kysela
2003-10-12 13:37 ` James Courtier-Dutton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F895936.8000707@superbug.demon.co.uk \
--to=james@superbug.demon.co.uk \
--cc=alsa-devel@lists.sourceforge.net \
--cc=perex@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox