On 12-06-08 08:28, Demian Martin wrote:
> I don't think we are in disagreement in substance. I was trying to
> give a larger framework for all of those not as familiar with the
> general workings and decisions behind computer audio as currently
> implemented. "Just works" is very important to most
I don't think we are in disagreement in substance. I was trying to give a
larger framework for all of those not as familiar with the general workings
and decisions behind computer audio as currently implemented. "Just works"
is very important to most users. But isn't right for some of us.
Somewher
On 12-06-08 05:52, Rene Herman wrote:
Oh, by the way, upon rereading:
> On 11-06-08 17:41, Dominique Michel wrote:
>> You must add some device definitions in /etc/modules.d/alsa (or
>> whatever file
>> your distribution is using):
>>
>> ## ALSA portion
>> alias snd-card-0 snd-...
>> options sn
On 12-06-08 07:17, Pete Black wrote:
> dmix *is* an application, conceptually it is not different [ ... ]
Let's call it a conceptlication then. As said, your basic description
was correct.
Rene.
-
Check out the new SourceF
On 12-06-08 07:13, Demian Martin wrote:
> Computer audio and sample rate issues are popping up everywhere, driven
> by the desire for high quality audio on PC's finally. On Windows and
> Mac's its even harder to get it right.
>
> In Alsa (and PC audio architecture in general) the system has a d
dmix *is* an application, conceptually it is not different to esd, artsd
or pulseaudio opening the ALSA hardware directly. It just happens to be
an ALSA plugin and is a part of the signal chain that ALSA-lib sets up
by default.
You can either:
a) configure dmix using a custom .asoundrc to use
Computer audio and sample rate issues are popping up everywhere, driven by
the desire for high quality audio on PC's finally. On Windows and Mac's its
even harder to get it right.
In Alsa (and PC audio architecture in general) the system has a default
sample rate, usually set by the driver it seem
On 12-06-08 06:53, Pete Black wrote:
> Its very simple.
>
> Most sound devices support a number of sample rates. Common ones
> include 16 bit @ 44.1khz, 16-bit @ 48khz, 24-bit @ 96 khz etc.
>
> Only one application has exclusive control over the sound hardware at
> any time.
>
> Whatever rate t
Its very simple.
Most sound devices support a number of sample rates. Common ones include
16 bit @ 44.1khz, 16-bit @ 48khz, 24-bit @ 96 khz etc.
Only one application has exclusive control over the sound hardware at
any time.
Whatever rate that application opens the soundcard at, is the rate th
On 12-06-08 06:30, Sergei Steshenko wrote:
> Yes again - to me ALSA's sample rate implementation looks quite
> illogical - IMO it should be the other way round - user first
> mandates sample rate, and then playback sources adapt through
> resampling if necessary.
Great setup once we have infinite
-Original Message-
From: Rene Herman <[EMAIL PROTECTED]>
To: Sergei Steshenko <[EMAIL PROTECTED]>
Date: Thu, 12 Jun 2008 05:55:40 +0200
Subject: Re: [Alsa-user] Output sample rate
>
> On 12-06-08 05:52, Sergei Steshenko wrote:
>
> > From: Rene Herman <[EMAIL PROTECTED]>
>
> > The samp
On 12-06-08 05:52, Sergei Steshenko wrote:
> From: Rene Herman <[EMAIL PROTECTED]>
> The sampling rate is a property inherent to the data.
> Are trying to tell me that sample rate is inherent to analog source connected
> to microphone or line input ?
Oh, not again... please get a clue. DATA.
R
On 11-06-08 17:41, Dominique Michel wrote:
> Le Tue, 10 Jun 2008 17:47:58 +0300,
> "alexander merkulov" <[EMAIL PROTECTED]> a écrit :
>
>> need to setup 2nd dummy card
>> how to do it?
>
> You must add some device definitions in /etc/modules.d/alsa (or whatever file
> your distribution is using)
-Original Message-
From: Rene Herman <[EMAIL PROTECTED]>
To: Sergei Steshenko <[EMAIL PROTECTED]>
Date: Thu, 12 Jun 2008 04:12:58 +0200
Subject: Re: [Alsa-user] Output sample rate
The sampling rate is a property inherent to the data.
>
> Rene.
???
Are trying to tell me that sample rat
On 12-06-08 02:17, Sergei Steshenko wrote:
> From: Grant <[EMAIL PROTECTED]>
>> Where is my output sample rate defined? I'm trying to make sure mpd
>> isn't resampling my music before it's sent to the USB DAC.
> I initiated a similar thread recently.
>
> The short answer - nowhere.
>
> As I w
On 12-06-08 00:35, Grant wrote:
> Where is my output sample rate defined? I'm trying to make sure mpd
> isn't resampling my music before it's sent to the USB DAC.
Check /proc/asound/card0/pcm0p/sub0/hw_params while mpd is playing (for
a suitable value of (0,0,0) ofcourse).
Rene.
-
-Original Message-
From: Grant <[EMAIL PROTECTED]>
To: alsa-user@lists.sourceforge.net
Date: Wed, 11 Jun 2008 15:35:42 -0700
Subject: [Alsa-user] Output sample rate
>
> Where is my output sample rate defined? I'm trying to make sure mpd
> isn't resampling my music before it's sent to t
Grant wrote:
> Where is my output sample rate defined? I'm trying to make sure mpd
> isn't resampling my music before it's sent to the USB DAC.
>
>
If you are playing audio that is in recognized format the rate is
defined within the audio file itself and was set at time of creation.
If you w
Where is my output sample rate defined? I'm trying to make sure mpd
isn't resampling my music before it's sent to the USB DAC.
- Grant
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell servi
Hi Jochen,
> 2. use a lower frame size, than my codec/systems framing. (e.g. 128
> instead of 256, but still transmit 256 in one pass)
Yes - a good idea, however, sometimes depending on the actual machine and OS
(or even low-latency patches) problems might occur when running below 256
samples
Hi Helge,
what we actually discuss is more a principle of the driver related to buffer
management and in how far this could reduce the latency. But thanks anyway !
-- A l e x
Original-Nachricht
> Datum: Wed, 11 Jun 2008 18:06:27 +0200
> Von: "Helge Fredriksen" <[EMAIL PROTECTE
Did you try the settings in /etc/security/limits.conf suggested on the
Frinika
front page? (http://frinika.sourceforge.net). I noticed quite some
difference in delay for
Terratec Aureon 5.1 Fun cards using JavaSound.
Helge F.
On Wed, Jun 11, 2008 at 10:11 AM, Clemens Ladisch <[EMAIL PROTECTED]>
w
Le Tue, 10 Jun 2008 17:47:58 +0300,
"alexander merkulov" <[EMAIL PROTECTED]> a écrit :
> need to setup 2nd dummy card
> how to do it?
You must add some device definitions in /etc/modules.d/alsa (or whatever file
your distribution is using):
## ALSA portion
alias snd-card-0 snd-...
options snd-.
Thanks for the hint, Clemens.
If I interpret this information correctly, then it seems that many
different sound drivers actually support pause, and consequently many
audio architectures have the functionality as well (or it is emulated by
the drivers). The real problem is the dmix plugin. In p
Florian Winter wrote:
> Is there another way to determine whether a certain hardware supports
> snd_pcm_pause without having to test the hardware?
$ grep -rl SNDRV_PCM_INFO_PAUSE sound
sound/arm/pxa2xx-pcm.c
sound/arm/sa11xx-uda1341.c
sound/core/pcm_native.c
sound/drivers/vx/vx_pcm.c
sound/pci/als
Hi,
The snd_pcm_pause function of the ALSA API is not supported on all audio
hardware.
Is there an official list (e.g. on the web) of known sound hardware,
which supports this feature? Is there another way to determine whether a
certain hardware supports snd_pcm_pause without having to test the
Alexander Carôt wrote:
> 3.) Rather than using a double buffer for the playout wouldn't it be
> possible to choose only one physical playout buffer and parse the
> captured data in right at the interrupt.
It's unlikely that any code could be fast enough to write the entire
buffer before the hardwa
stan wrote:
> Florian Faber wrote:
> > You want hardware monitoring - there are sound cards that support
> > hardware mixing. With good converters you have latencies down to 5
> > samples at 192kHz, that would be 0.026ms for each way, 0.052ms over
> > all.
>
> I'm not the original poster, but I'm c
28 matches
Mail list logo
