On Fri, 10 Jan 2003, Troy Benjegerdes wrote:
> > > results in alsa-kernel/core/pcm_memory.c:alloc_pcm_pages() getting
> > > called with substream->dma_type= SNDRV_PCM_DMA_TYPE_UNKNOWN.
> >
> > oh, you found a bug :) it was introduced due to my last change to pcm
> > pre-allocator. now fixed on
Hi,
I own a soundblaster 4.1 and I experience the following problem: I can't get
the rear channel to work. There isn't even a volume control for it (neither
in amixer nor in alsamixer). I'm using the snd-ens1371 driver that should do
the job.
The card is a basic design using a CT5880 PCI contr
>That is, of course, not an acceptable solution, and it also doesn't
>work when you're using the ALSA sequencer interface (at least from the
>API calls I've seen). Fixing it in the driver requires interpreting
>much MIDI, possibly buffering, and has some problems (what if someone
>writes an incomp
No dice. :-/
I played around with some of my own changes that did the same thing, as
well as your patch, and I always get nothing on the receiver.
What next? try an x86 box and make sure it works with that? Is there
something In the ymfpci driver I should look at? (also, are there any
IRC channel
I'm using alsa-0.9.0rc6 with a 2.4.18 kernel (low-latency patch applied).
Sound card is a Terratec EWX 24/96. My problem is the following:
at startup the master clock rate is at 48KHz. If I try to change it to
44.1KHz with alsamixer, amixer or envy24control it stays fixed at 48.
HOWEVER if I set t
>> i'm afraid its an entirely acceptable solution, and its the same one
>> required by many other non-audio, non-MIDI device types. if you have
>> multiple threads writing to a disk-file, for example, and they
>> interleave their calls to write(2), you will get mixed up data on
>> disk.
>
>Actually
On Sat, 11 Jan 2003 18:31:51 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> not really. the mtpav is a "non-standard" device that uses special
> values in the datastream to switch its output port. the ALSA sequencer
> can't know this, and so it can't have any idea that strange things are
> happeni
On Sat, 11 Jan 2003 15:46:15 +0100 (CET)
Jaroslav Kysela <[EMAIL PROTECTED]> wrote:
> ALSA driver should handle this correctly (at least current CVS code).
> The write sequence is locked.
Hrm, I'll check through the code---after playing with it, it doesn't
appear things are 100% yet. I had dece
>That's what drivers are for. ;) The ALSA sequencer shouldn't have to
>know of course, but the driver should be able to handle it, and the
>architecture should allow a working driver.
i'd agree with that.
>> another example of this that i know a bit more about is on the
>> tropez+. this has two