Hi,
here are my current config
lspci -v
00:1f.5 Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 02)
Subsystem: Siemens Nixdorf AG: Unknown device 0051
Flags: bus master, medium devsel, latency 0, IRQ 5
I/O ports at 2000 [size=256]
I/O ports at
Isn't it really nice that there are ioctls and library functions to get/
set the midi_voices property of sequencer ports?
Well, it would be, if ports actually had this property. :o)
Index: alsa-kernel/core/seq/seq_ports.h
===
RCS
Takashi Iwai wrote:
could you resend the patch if finished?
The new parsing code works with my device (UA-1A), but I couldn't test the
changes for the mixer and the UA-20.
- removed buffer allocation for class-specific descriptors; get them from
intf-extra and ep-extra.
- accept
At Fri, 28 Feb 2003 14:51:08 +0900,
Patrick Shirkey wrote:
Takashi Iwai wrote:
hmm, the hot unplugging of ALSA usb devices was improved in the recent
version - basically i didn't see problems with the devices i have.
but i've not tested with midi devices, so this might be a problem.
At 26 Feb 2003 20:47:41 -0800,
Mark Knecht wrote:
If I then change my keyboard to drive the HDSP 9652 input 1 (Alsa
64:0) and change the connections internally to drive all of outputs, I
get stuck notes pretty much immediately. It seems a bit worse with the
sustain pedal, but does not
Hello,
there's a bug introduced in the 1.25 revision of the file
alsa-kernel/core/control.c which is fixed with the attached patch.
Please apply :-)
Bye,
--
Arnaud
--- alsa-kernel/core/control.c 2003-01-13 10:49:43.0 +0100
+++ alsa-kernel/core/control.c 2003-02-28 13:27:58.0
On Fri, 2003-02-28 at 04:14, Takashi Iwai wrote:
At 26 Feb 2003 20:47:41 -0800,
Mark Knecht wrote:
If I then change my keyboard to drive the HDSP 9652 input 1 (Alsa
64:0) and change the connections internally to drive all of outputs, I
get stuck notes pretty much immediately. It
On Fri, 28 Feb 2003, Arnaud de Bossoreille de Ribou wrote:
Hello,
there's a bug introduced in the 1.25 revision of the file
alsa-kernel/core/control.c which is fixed with the attached patch.
I've applied a better fix to CVS. Thanks for your notice.
On Fri, 2003-02-28 at 04:56, Mark Knecht wrote:
at least, we need to check whether the interrupts for MIDI are
generated properly.
please try the following.
1. connect HDSP MIDI1 input to HDSP MIDI1 output via aconnect.
2. trigger a note from MIDI1 input.
check whether the IRQ
At Fri, 28 Feb 2003 12:33:02 +0100 (MET),
Clemens Ladisch wrote:
Takashi Iwai wrote:
could you resend the patch if finished?
The new parsing code works with my device (UA-1A), but I couldn't test the
changes for the mixer and the UA-20.
- removed buffer allocation for class-specific
At Fri, 28 Feb 2003 12:57:21 +0100 (MET),
Clemens Ladisch wrote:
Isn't it really nice that there are ioctls and library functions to get/
set the midi_voices property of sequencer ports?
Well, it would be, if ports actually had this property. :o)
egg or chicken? :)
thanks, now on cvs.
Hi Paul,
At Thu, 27 Feb 2003 13:43:34 -0500,
Paul Davis wrote:
i haven't had time today to get the patch for the hdsp ready. however,
the new source works here (i have some CVS sync issues). i'll get it
out to the list on monday (i'm gone for the weekend).
could you check the attached patch
Hi,
i changed the management of (PCM) DMA buffers on the cvs version.
now there is a new module, snd-page-alloc, which includes the generic
memory allocators for various (bus) types. this module is independent
from snd module, so that it can keep the allocated buffers after snd-*
modules are
At Thu, 27 Feb 2003 03:01:46 +0900,
Patrick Shirkey wrote:
I'm wondering if this is a bug that can be fixed or not.
The following has been submitted as a note for the documentation of via82xx.
sender: [EMAIL PROTECTED]
date: Saturday, 18 January 2003
I don't
Hallo,
Clemens Ladisch hat gesagt: // Clemens Ladisch wrote:
The new parsing code works with my device (UA-1A), but I couldn't test the
changes for the mixer and the UA-20.
I'm sorry, that I cannot test this anymore on the UA-20 that was mine until
today, 11:00 :( when I sent it back.
But I'd
Takashi Iwai wrote:
I see it too with the quattro and another user has reported it with the
audigy. It would be nicer if we didn't have to remember to unload the
usb-audio driver before hotplugging. Is it possible to make that happen.
then there is still a bug in this regard.
are you using
Jaroslav Kysela wrote:
Note that we have actually the experimental dmix plugin (direct mixing)
which works for i386 architecture in CVS. The usage is simple:
aplay -Dplug:dmix filename
You may pass 'plug:dmix' to any other application.
When I try this I get this error:
~$ aplay -D plug:dmix
Patrick Shirkey wrote:
Takashi Iwai wrote:
I see it too with the quattro and another user has reported it with
the audigy. It would be nicer if we didn't have to remember to unload
the usb-audio driver before hotplugging. Is it possible to make that
happen.
then there is still a bug in this
On Sat, 1 Mar 2003, Patrick Shirkey wrote:
Jaroslav Kysela wrote:
Note that we have actually the experimental dmix plugin (direct mixing)
which works for i386 architecture in CVS. The usage is simple:
aplay -Dplug:dmix filename
You may pass 'plug:dmix' to any other application.
At 27 Feb 2003 12:35:00 -0800,
Fernando Pablo Lopez-Lezcano wrote:
lists about this and to do it cleanly it would be nice to have available
in /proc/asound the list of modules currently loaded. That is not
available today (I think Takashi said he might add that).
cat /proc/modules |
20 matches
Mail list logo