According to the alsa documentation, the return value of
snd_hw_params_set_rate_near is the 'approximate chosen rate', and the
3rd arg being type 'int'. The two tutorials at the documentation
section of the alsa-project website both hold true to this with code like:
exact_rate = snd_pcm_hw_par
I installed a M-Audio Revolution 7.1 (snd-ice1724) in my mythtv box. I
had mythtv working fine with the machine's onboard sound (snd-trident)
using OSS emulation. The revo works correctly for things like xine,
mplayer, aplay (of course), play, etc. In mythtv, however, I get no
sound.
I dug into t
Hallo,
James Courtier-Dutton hat gesagt: // James Courtier-Dutton wrote:
> You will be lucky to find any sound card complying with the USB Audio
> spec, as the spec is written so badly.
This is the USB spec I'm referring, not the USB AUDIO spec. Those
M-Audio devices aren't even recognized as be
Frank Barknecht wrote:
Hallo,
I'd like to propose changing the status of three M-Audio USB
devices in the soundcard matrix to "unsupported on 2.6". The Quattro,
Audiophile USB and reportedly the Duo all don't comply to the USB
specification, as has been discussed here and on linux-usb-dev in the
r
Hallo,
I'd like to propose changing the status of three M-Audio USB
devices in the soundcard matrix to "unsupported on 2.6". The Quattro,
Audiophile USB and reportedly the Duo all don't comply to the USB
specification, as has been discussed here and on linux-usb-dev in the
recent past.
Thus they
Hello,
I'm trying to set my ppq on my queue, so I do this:
snd_seq_queue_tempo_t *qt;
snd_seq_queue_tempo_alloca(&qt);
snd_seq_queue_tempo_set_ppq(qt, ppq);
return snd_seq_set_queue_tempo(seq, id, qt);
where id is my queue id and ppq the new ppq. This is quite similar to the way I
This is the first shot at this - I've tested it on ARM, covering both
ISA ALSA devices on a PCI machine, and driver model devices on a non-
PCI, non-ISA machine. However, it needs more testing. Can people
on alsa-devel please test these patches.
Convert remaining PCI-using functions to use the d
This is the first shot at this - I've tested it on ARM, covering both
ISA ALSA devices on a PCI machine, and driver model devices on a non-
PCI, non-ISA machine. However, it needs more testing. Can people
on alsa-devel please test these patches.
Convert PCI-based memory allocators to use the new
This is the first shot at this - I've tested it on ARM, covering both
ISA ALSA devices on a PCI machine, and driver model devices on a non-
PCI, non-ISA machine. However, it needs more testing. Can people
on alsa-devel please test these patches.
This patch adds support for the generic device/dri
Did you ever try it in windows, too see if it was possible at all? I
just snagged a second card off ebay, so I will be experimenting with
this soon, too.
Ludwig Schwardt wrote:
Hi,
My quest for syncing two Delta 1010LTs under ALSA has gone on hold for
the time being... No success so far. Both
On Sun, 29 Feb 2004, Russell King wrote:
> On Sun, Feb 29, 2004 at 01:31:01PM +0100, Jaroslav Kysela wrote:
> > On Sun, 29 Feb 2004, Russell King wrote:
> > > Could someone enlighten me about the way alsa-lib / alsa-driver are
> > > supposed to work when using mmap mode please? I'm looking at the
On Sun, Feb 29, 2004 at 01:31:01PM +0100, Jaroslav Kysela wrote:
> On Sun, 29 Feb 2004, Russell King wrote:
> > Could someone enlighten me about the way alsa-lib / alsa-driver are
> > supposed to work when using mmap mode please? I'm looking at the 1.0.2
> > code, along with madplay and Linux 2.6.
Hello all,
it was quite busy month for the ALSA development. The 1.0.3
packages were released. I would like to note that most of problems with
rate resampling plugin were solved (thus indirectly the most of dmix
issues, too). Also, aoss wrapper code (alsa-oss package) was recoded
and im
On Sun, Feb 29, 2004 at 01:48:52PM +0100, Jaroslav Kysela wrote:
> On Sun, 29 Feb 2004, Russell King wrote:
> >I believe this needs discussing with the DMA API authors on LKML since
> >AFAIK the kernel currently doesn't have a clear API to translate memory
> >returned by either pci_allo
On Sun, 29 Feb 2004, Simon Oosthoek wrote:
> > Unfortunately, the dmix plugin does not work with arts, because arts does
> > not follow the ALSA API for file descriptor handling. I've already
> > contacted the arts author this week, but he has not sent any reply to me.
>
> is there a bug on the
On Sun, 29 Feb 2004, Russell King wrote:
> 1) Memory types.
>
>In snd_dma_alloc_pages(), ALSA does this:
>
> case SNDRV_DMA_TYPE_PCI:
> dmab->area = snd_malloc_pci_pages(dev->dev.pci, size, &dmab->addr);
>
>which eventually comes down to this:
>
> res =
Hi,
My quest for syncing two Delta 1010LTs under ALSA has gone on hold for
the time being... No success so far. Both cards work fine separately.
The main problem is that I cannot get either a word clock output or
SPDIF output going. Both these digital outputs remained dead no matter
what I did
On Sun, 29 Feb 2004, Russell King wrote:
> Hi,
>
> Could someone enlighten me about the way alsa-lib / alsa-driver are
> supposed to work when using mmap mode please? I'm looking at the 1.0.2
> code, along with madplay and Linux 2.6.4-rc1.
>
> madplay sets the start_threshold to the size of the
1) Memory types.
In snd_dma_alloc_pages(), ALSA does this:
case SNDRV_DMA_TYPE_PCI:
dmab->area = snd_malloc_pci_pages(dev->dev.pci, size, &dmab->addr);
which eventually comes down to this:
res = pci_alloc_consistent(pci, PAGE_SIZE * (1 << pg), dma_addr);
Hi,
Could someone enlighten me about the way alsa-lib / alsa-driver are
supposed to work when using mmap mode please? I'm looking at the 1.0.2
code, along with madplay and Linux 2.6.4-rc1.
madplay sets the start_threshold to the size of the buffer, and min_avail
to one period size - in much the
20 matches
Mail list logo
