I have a Fujitsu E7110 laptop with a builtin audio card. This is what lspci
reports...
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev
02)
Subsystem: Citicorp TTI: Unknown device 1177
Flags: bus master, medium devsel, latency 0, IRQ 11
Any comments on this would be really helpful...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gupta,
Kshitij
Sent: Wednesday, March 10, 2004 5:06 PM
To: [EMAIL PROTECTED]
Subject: [Alsa-devel] DMA producer/consumer
hi,
A typical core pcm playbac
Hi,
> What about 7.1 surround sound channels. All your suggestions only assume
> 2 PCM channels.
Lets clarify something: A 3D stream is one mono stream, that is split
into all the necesary channels with the corresponding processing for
whatever amount of speaker / headphones you have, to get th
Hi Ove,
On Wed, 2004-03-10 at 10:16, Ove Kaaven wrote:
> > Please start writing what the API should provide.
>
> Well, the requirements that raised this thread should be fairly clear.
> For example,
>
> ALTERNATIVE 1
>
> snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
>
> and
>
> snd_pcm_set_p
Karsten Wiese wrote:
We can also vary the exact USB frame time.
With UHCI 1.1 USB Hosts there is the SOF Register.
It is setable from 0 to 255, the default being 127.
Using this SOF-Register, we can set the actual USB Frame Rate from
((12000 - 127) / 12000)ms to ((12000 + 128) / 12000)ms. That is
Luca <[EMAIL PROTECTED]> writes:
> Hi,
> I'm using linux 2.6.3 with alsalib 1.0.2c. When using alsa output plugin
> of XMMS or mplayer the song is played too fast. Using OSS emulation
> works fine.
>
> This is from bootlog:
>
> intel8x0_measure_ac97_clock: measured 49482 usecs
> intel8x0: clocking
We can also vary the exact USB frame time.
With UHCI 1.1 USB Hosts there is the SOF Register.
It is setable from 0 to 255, the default being 127.
Using this SOF-Register, we can set the actual USB Frame Rate from
((12000 - 127) / 12000)ms to ((12000 + 128) / 12000)ms. That is about -/+ 1%:
More t
Hi,
I'm using linux 2.6.3 with alsalib 1.0.2c. When using alsa output plugin
of XMMS or mplayer the song is played too fast. Using OSS emulation
works fine.
This is from bootlog:
intel8x0_measure_ac97_clock: measured 49482 usecs
intel8x0: clocking to 48000
And this is the sound card (chiset is S
Takashi Iwai wrote:
> Clemens Ladisch wrote:
> >
> > > I don't know much about USB 2.0,
> >
> > Not too much differences for the driver. The main difference is that
> > there are now 8000 microframes per second. I have written a patch
> > (see below) and am about to test it.
>
> is there any "rea
Hey
This is the nth day I'm stuck reading the ALSA-documentation over and over again, and I'm at a loss figuring out whats wrong.
Basically, I have a running thread capturing data from an ALSA-device, and within useconds I get: "samptest: pcm.c:5889: snd_pcm_mmap_commit: Assertion `frame
> I think we've to split the theme to different parts.
>
> - an usb driver for the Noah with the capabilitiy to use both usb
> configurations (control and midi/audio) at the same time.
>
> -an another (pci)driver to support the creamware DSP-cards.
>
> - an user-space application to manage the d
Takashi Iwai wrote:
> At Wed, 10 Mar 2004 11:28:39 +0100 (MET),
> Clemens Ladisch wrote:
> >
> > AFAIK drivers for ATI hardware are developed in a similar way (ATI
> > gives specs under an NDA, the resulting driver is open source).
> >
> > Takashi, is that right?
>
> yes. but just make sure tha
Ove Kaaven wrote:
Well, the requirements that raised this thread should be fairly clear.
For example,
ALTERNATIVE 1
snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
and
snd_pcm_set_pan(snd_pcm_t* pcm, int pan)
using whatever value range makes the most sense, and perhaps some query
on whether th
At Wed, 10 Mar 2004 16:55:05 +0100 (CET),
Giuliano Pochini wrote:
>
> There also is another important question: What is the unit used
> to set the gain ? Decibel is probably the right choice, but
> the control API provides no way to translate the dB scale to the
> scale used by the hardware.
dB
ons, 10.03.2004 kl. 16.55 skrev Giuliano Pochini:
> Uhm... I think first of all we need a way to know how many
> virtual channels are available (hw and sw)
For the EMU10K1, snd_pcm_info_get_subdevices_count() and
snd_pcm_info_get_subdevices_avail() works for me. But I suppose you're
right that thi
At Wed, 10 Mar 2004 09:26:27 +0100 (MET),
Clemens Ladisch wrote:
>
> > I don't know much about USB 2.0,
>
> Not too much differences for the driver. The main difference is that
> there are now 8000 microframes per second. I have written a patch
> (see below) and am about to test it.
is there a
ons, 10.03.2004 kl. 16.08 skrev Takashi Iwai:
> At Wed, 10 Mar 2004 15:16:34 +0100,
> Ove Kaaven wrote:
> >
> > > Please start writing what the API should provide.
> >
> > Well, the requirements that raised this thread should be fairly clear.
> > For example,
> >
> > ALTERNATIVE 1
> >
> > snd_p
On 10-Mar-2004 Ove Kaaven wrote:
> Well, the requirements that raised this thread should be fairly clear.
> For example,
>
> ALTERNATIVE 1
>
> snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
>
> and
>
> snd_pcm_set_pan(snd_pcm_t* pcm, int pan)
>
> using whatever value range makes the most sense, a
At Wed, 10 Mar 2004 15:16:34 +0100,
Ove Kaaven wrote:
>
> > Please start writing what the API should provide.
>
> Well, the requirements that raised this thread should be fairly clear.
> For example,
>
> ALTERNATIVE 1
>
> snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
>
> and
>
> snd_pcm_set_
>In any case, most of this can all be handled by software. The only stuff
>the hardware really need is the volume, frequency, direction to sound
>source, and any additional effects (such as reverb). Application
>software can deal with the rest.
i can certainly see the utility of such an API. howev
ons, 10.03.2004 kl. 15.16 skrev Ove Kaaven:
> * Volume
> * Pan (not available if 3D sound is requested)
> * Frequency (can be used for software-calculated doppler shift, or for
> "wavetable synthesis"-like purposes)
> * 3D position (relative to listener)
> * Velocity (for hardware-calculated dopple
ons, 10.03.2004 kl. 10.46 skrev Giuliano Pochini:
> On 09-Mar-2004 Ove Kaaven wrote:
> > Since we're ranting anyway: It's a similar situation with 3D graphics
> > hardware, where the 3D cards get ever more powerful, even though the CPU
> > power is going up. [...]
>
> No need to enter the philosop
hi,
A typical core pcm playback flow (simplified for representation)
static void arch_pcm_start_dma(struct arch_pcm_runtime *s)
{
...
ret = __arch_start_dma(s->dma_ch, pos, s->dma_size);
...
ssr->dma_pos = pos;
}
static void arch_pcm_dma_
At Wed, 10 Mar 2004 11:28:39 +0100 (MET),
Clemens Ladisch wrote:
>
> Willie Sippel wrote:
> > > But I'm not sure about, wether the NDA agrees in the basic alsa
> > > principles. What are the developers of alsa are thinking about that
> > > agreement?
>
> AFAIK drivers for ATI hardware are develop
Willie Sippel wrote:
> > But I'm not sure about, wether the NDA agrees in the basic alsa
> > principles. What are the developers of alsa are thinking about that
> > agreement?
AFAIK drivers for ATI hardware are developed in a similar way (ATI
gives specs under an NDA, the resulting driver is open
On 09-Mar-2004 Ove Kaaven wrote:
> Independently? No, our software mixing code resamples, adjusts volume,
> and mixes the stream into the buffer in one step.
It should be more efficient than separate passes. It minimizes
memory i/o and some operation (multiply-add == volume-mix) can
be done nati
At Wed, 10 Mar 2004 10:08:26 +0100 (CET),
Jaroslav wrote:
>
> On Wed, 10 Mar 2004, Clemens Ladisch wrote:
>
> > Jaroslav Kysela wrote:
> >
> > > On Tue, 9 Mar 2004, Takashi Iwai wrote:
> > >
> > > > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > > > perfectly suitab
Jaroslav Kysela wrote:
> On Wed, 10 Mar 2004, Clemens Ladisch wrote:
>
> > Conceptually, USB devices have variable-sized periods. The question
> > is whether we actually want to allow this in the API. Probably not.
>
> What this does mean? I though that the period size is specified with time
> (
On Wed, 10 Mar 2004, Clemens Ladisch wrote:
> Jaroslav Kysela wrote:
>
> > On Tue, 9 Mar 2004, Takashi Iwai wrote:
> >
> > > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > > perfectly suitable for the devices like USB audio.
> >
> > Unfortunately I don't see a better
Jaroslav Kysela wrote:
> On Tue, 9 Mar 2004, Takashi Iwai wrote:
>
> > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > perfectly suitable for the devices like USB audio.
>
> Unfortunately I don't see a better model.
Conceptually, USB devices have variable-sized period
30 matches
Mail list logo