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 curious
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 hardware
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
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
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
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-...
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]
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 PROTECTED]
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
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
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 want
-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 the
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.
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 was
-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 rate is
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):
## ALSA
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.
Rene.
-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 sampling rate is
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 infinitely
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
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 that
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
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
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
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
25 matches
Mail list logo
