This patch removes the implicit assumption that devices with
QUIRK_MIDI_FIXED_ENDPOINT use the same endpoint number for input and
output pipes. (This broke with the Edirol PCR-30/50.)
Index: alsa-kernel/usb/usbaudio.h
===
RCS file:
At Fri, 10 Jan 2003 09:17:28 +0100,
Joachim Blaabjerg wrote:
On Thursday 09 January 2003 18:01, Takashi Iwai wrote:
Hi,
if someone has VIA8233, VIA8233A, VIA8233C or VIA8235 chipset, could
you help the testing of the new driver?
the new driver code is found at
At Fri, 10 Jan 2003 10:13:58 +0100,
Joachim Blaabjerg wrote:
On Friday 10 January 2003 09:37, Takashi Iwai wrote:
At Fri, 10 Jan 2003 09:17:28 +0100,
Joachim Blaabjerg wrote:
On Thursday 09 January 2003 18:01, Takashi Iwai wrote:
Hi,
if someone has VIA8233, VIA8233A,
On Friday 10 January 2003 10:27, you wrote:
there are small bugs regarding the calculation of hw-pointer.
i hope now this choppy sounds fixed. could you try to grab via82xx.c
again from the same url?
Yes, works great! Everything I use my card for works 100% now, for the first
time I can
At Fri, 10 Jan 2003 09:08:47 +0100 (MET),
Clemens Ladisch wrote:
This patch removes the implicit assumption that devices with
QUIRK_MIDI_FIXED_ENDPOINT use the same endpoint number for input and
output pipes. (This broke with the Edirol PCR-30/50.)
thanks, now committed to cvs.
the patch
At Fri, 10 Jan 2003 00:55:45 -0600,
Troy Benjegerdes wrote:
On Tue, Jan 07, 2003 at 05:02:53PM +0100, Takashi Iwai wrote:
At Thu, 2 Jan 2003 22:22:34 -0600,
Troy Benjegerdes wrote:
I have a mac G4 (running debian testing), a ymfpci card (MaxiSound
Fortissimo) with
Hi,
At Tue, 10 Dec 2002 08:39:35 -0800, Takashi Iwai wrote:
At Tue, 10 Dec 2002 13:50:31 +0100, Christian Guggenberger wrote:
I get following oops while unloading snd-intel8x0 on a Dell Optiplex 260
hmm, it's a new type of oops, which i've never seen.
I had the same problem using a Gericom
Hi Enrik,
At Fri, 10 Jan 2003 13:37:32 +0100,
Enrik Berkhan wrote:
Hi,
At Tue, 10 Dec 2002 08:39:35 -0800, Takashi Iwai wrote:
At Tue, 10 Dec 2002 13:50:31 +0100, Christian Guggenberger wrote:
I get following oops while unloading snd-intel8x0 on a Dell Optiplex 260
hmm, it's a new
This gives additional details about the blocking with the sb16 driver:
Bernard Urban [EMAIL PROTECTED] writes:
[...]
quakeforge with alsa sound output and alsa driver has the time lag
(nearly 0.5 second).
quakeforge with OSS sound output and OSS 'sb' driver works well.
quakeforge with OSS
On Sun, Jan 05, 2003 at 04:46:47PM +0100, Anders Torger wrote:
Here is a patch against rme96.c
snd_rme96_capture_spdif_open(snd_pcm_substream_t *substream)
[...]
+ runtime-hw = snd_rme96_capture_spdif_info;
+if ((rate = snd_rme96_capture_getrate(rme96, isadat)) 0) {
+
On Tue, Jan 07, 2003 at 05:02:53PM +0100, Takashi Iwai wrote:
At Thu, 2 Jan 2003 22:22:34 -0600,
Troy Benjegerdes wrote:
I have a mac G4 (running debian testing), a ymfpci card (MaxiSound
Fortissimo) with optical TOSlink out, and a yamaha HTR-5540 receiver with
There
On Friday 10 January 2003 15.53, Martin Langer wrote:
On Sun, Jan 05, 2003 at 04:46:47PM +0100, Anders Torger wrote:
Here is a patch against rme96.c
snd_rme96_capture_spdif_open(snd_pcm_substream_t *substream)
[...]
+ runtime-hw = snd_rme96_capture_spdif_info;
+if ((rate =
At Fri, 10 Jan 2003 16:13:07 +0100,
Anders Torger wrote:
As mentioned before, this driver does not yet handle the cases when
sample rate and other properties is changed in runtime (I don't know if
ALSA is complete in that respect either).
as far as i've tested before (vari-speed playback
Hi,
i updated the SG-buffer handling routines to use vm-mapping.
if you have emu10k1, via82xx or trident 4DNX, please try the patch at
http://www.alsa-project.org/~iwai/vm-sgbuf.dif
it includes patches to both alsa-kernel and alsa-tree (the very latest
cvs version).
at least, it works
At Fri, 10 Jan 2003 11:09:32 +0100,
Joachim Blaabjerg wrote:
On Friday 10 January 2003 10:27, you wrote:
there are small bugs regarding the calculation of hw-pointer.
i hope now this choppy sounds fixed. could you try to grab via82xx.c
again from the same url?
Yes, works great!
Basically, the problem is this. The MTP/AV protocol takes messages
like this:
Dn B1 ... Bn
Where Dn is the device number, and B1..Bn are the midi message bytes.
This, at least, is what I gather from talking to Michael Mayers, the
original driver developer.
You may see the problem now. When
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 cvs.
thanks for your report!
Okay, now we're getting
17 matches
Mail list logo
