Merrony, Stephen (London) wrote:
> I would like to be able to query the number of MIDI channels available per
> client, but all of snd_seq_port_info_get_midi_channels(),
> snd_seq_port_info_get_midi_voices(), snd_seq_port_info_get_synth_voices()
> return 0.
>
> I am using a Creative SoundBlaster L
Frank Neumann wrote:
> I have written a small helper program (for myself so far) that should allow
> me to get a backup of all data from a Korg M3r expander through the ALSA
> rawmidi API. I have written a first version that opens the rawmidi device,
> tells the user to "start the dump on the M3r",
OK - at least it's not my dodgy programming that's to blame this time [;-)
Is it either (i) correct, (ii) safe, or (iii) OK in practice(!), to assume
16 channels per (wavetable) synth?
Thanks
Steve
> Merrony, Stephen (London) wrote:
> > I would like to be able to query the number of
alsa-{kernel,lib} cvs, kernel 2.5.49, audigy2 platinum.
Output jack adjacent to firewire connector works; "Wave Surround"
volume control functions normally.
The next jack over also works; its left and right channel volumes
are controlled independently by "Wave LFE" and "Wave Center".
The output
On Wed, 5 Feb 2003, Merrony, Stephen (London) wrote:
> OK - at least it's not my dodgy programming that's to blame this time [;-)
>
> Is it either (i) correct, (ii) safe, or (iii) OK in practice(!), to assume
> 16 channels per (wavetable) synth?
It would be better to use midi_channels() functio
At Wed, 5 Feb 2003 09:48:43 -,
Merrony, Stephen (London) <[EMAIL PROTECTED]> wrote:
>
> OK - at least it's not my dodgy programming that's to blame this time [;-)
>
> Is it either (i) correct, (ii) safe, or (iii) OK in practice(!), to assume
> 16 channels per (wavetable) synth?
(iii).
if it
Thanks - let me know if you want a tester.
Steve
> -Original Message-
> From: Takashi Iwai [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, February 05, 2003 10:41 AM
> To: Merrony, Stephen (London)
> Cc: 'Clemens Ladisch'; [EMAIL PROTECTED]
> Subject: Re: [Alsa-devel] Sequencer API Q
At Wed, 5 Feb 2003 10:42:55 -,
Merrony, Stephen (London) <[EMAIL PROTECTED]> wrote:
>
> Thanks - let me know if you want a tester.
the new code is already on cvs.
please let me know if the problem still persists.
thanks,
Takashi
---
Thi
At Mon, 3 Feb 2003 13:38:15 + (GMT),
Chris Rankin wrote:
>
> --- Takashi Iwai <[EMAIL PROTECTED]> wrote:
> > Hi Chris,
> >
> > At Fri, 31 Jan 2003 19:56:51 + (GMT),
> > Chris Rankin wrote:
> > >
> > > --- Takashi Iwai <[EMAIL PROTECTED]> wrote:
> > > > do you know which version (or dat
Hi,
At Wed, 5 Feb 2003 03:51:09 -0600,
Mark J Roberts wrote:
>
> alsa-{kernel,lib} cvs, kernel 2.5.49, audigy2 platinum.
>
> Output jack adjacent to firewire connector works; "Wave Surround"
> volume control functions normally.
>
> The next jack over also works; its left and right channel
On Mon, 3 Feb 2003, Sebastian Kapfer wrote:
> The alsa-lib doesn't set the close-on-exec flag on its PCM device FD's.
> The consequence is that processes spawned by alsa-lib clients inherit an
> open file handle to the PCM device and thereby block it.
>
> For example, mplayer can disable and re-l
At Tue, 4 Feb 2003 14:30:30 +0100 (CET),
Jaroslav Kysela wrote:
>
> Hi all,
>
> I've commited improved kernel code for the ALSA timer interface.
> It should fix many troubles (my own lowlatency kernel with HZ=1000 easily
> hung up my laptop when I used older code for the system timer) and
At Wed, 5 Feb 2003 12:20:23 +0100 (CET),
Jaroslav wrote:
>
> Well, I and Abramo think that it's better to force application developers
> to clean allocated things before they'll call exec().
the problem is not only the explicit exec() call.
without this bit, you'll pass the fds to other processe
On Wed, 5 Feb 2003, Takashi Iwai wrote:
> At Wed, 5 Feb 2003 12:20:23 +0100 (CET),
> Jaroslav wrote:
> >
> > Well, I and Abramo think that it's better to force application developers
> > to clean allocated things before they'll call exec().
>
> the problem is not only the explicit exec() call.
On Wed, 5 Feb 2003, Takashi Iwai wrote:
> At Tue, 4 Feb 2003 14:30:30 +0100 (CET),
> Jaroslav Kysela wrote:
> >
> > Hi all,
> >
> > I've commited improved kernel code for the ALSA timer interface.
> > It should fix many troubles (my own lowlatency kernel with HZ=1000 easily
> > hung up my
At Wed, 5 Feb 2003 14:05:36 +0100 (CET),
Jaroslav wrote:
>
> On Wed, 5 Feb 2003, Takashi Iwai wrote:
>
> > At Wed, 5 Feb 2003 12:20:23 +0100 (CET),
> > Jaroslav wrote:
> > >
> > > Well, I and Abramo think that it's better to force application developers
> > > to clean allocated things before th
Speaking as a userspace developer, I expect file
descriptors to be inherited by child processes unless
I explicitly request otherwise. Yes, I usually make
sure that I *DO* request otherwise, but that's not the
point...
Cheers,
Chris
--- Takashi Iwai <[EMAIL PROTECTED]> wrote: > At Wed, 5
Feb 200
At Wed, 5 Feb 2003 12:17:28 +0100 (CET),
Jaroslav wrote:
>
> On Wed, 5 Feb 2003, Takashi Iwai wrote:
>
> > At Tue, 4 Feb 2003 14:30:30 +0100 (CET),
> > Jaroslav Kysela wrote:
> > >
> > > Hi all,
> > >
> > > I've commited improved kernel code for the ALSA timer interface.
> > > It should fix
>Speaking as a userspace developer, I expect file
>descriptors to be inherited by child processes unless
>I explicitly request otherwise. Yes, I usually make
>sure that I *DO* request otherwise, but that's not the
>point...
the question is not about inheritance by child processes. its about
close-
Takashi Iwai:
> what kind of output is expected on this jack?
Line one output. The working jacks are outputs two and three.
> this might be a bug of the driver, but not sure, atm.
> could you check whether interrupt counts increase when you receive a
> midi input?
They don't. MIDI _output_ gener
Hi Frank,
At Wed, 5 Feb 2003 00:34:41 +0100,
Frank Neumann wrote:
>
>
> Hi list,
>
> I have written a small helper program (for myself so far) that should allow
> me to get a backup of all data from a Korg M3r expander through the ALSA
> rawmidi API. I have written a first version that opens th
Hello,
I am trying to write a pcm_jack plugin, which would allow existing alsa
applications to use jack as input/output, without changing any code. The
plugin will use some internal circular buffer for the data transfer
between the alsa read/write calls and the async jack process callback.
I have
Hi Takashi,
Takashi Iwai <[EMAIL PROTECTED]> writes:
> At Mon, 3 Feb 2003 13:17:37 +0100,
> Richard Olsson wrote:
> >
> > On Mon, 03 Feb 2003 12:21:33 +0100
> > Takashi Iwai <[EMAIL PROTECTED]> wrote:
> >
> > > could you try the latest cvs version?
> > > i just changed a little the code.
> > >
Fair enough, but my point is that I'd expect the
close-on-exec flag NOT to be set unless I explicitly
set it myself. Same as with every other way of getting
a file descriptor.
Chris
--- Paul Davis <[EMAIL PROTECTED]> wrote: >
>Speaking as a userspace developer, I expect file
> >descriptors to be
Hi list,
Takashi Iwai <[EMAIL PROTECTED]> wrote:
[..]
> > Normally, according to the M3r's SysEx implementation in its manual,
> > this should give the same output, exactly 23963 bytes.
> > However, the second version loses about 130 bytes during the transfer.
> > The strange thing is that the b
The soundcard matrix shows the Waveterminal 192's as supportable but
not supported. I assume this is because someone here in ALSA land has
the tech data on its microcode (EEPROM version 120). Whoever has it,
please send it to me or point me to it, so I can get this card
working.
TIA!
-
On Wed, 5 Feb 2003, Maarten de Boer wrote:
> Hello,
>
> I am trying to write a pcm_jack plugin, which would allow existing alsa
> applications to use jack as input/output, without changing any code. The
> plugin will use some internal circular buffer for the data transfer
> between the alsa read/
--- Sebastian Kapfer <[EMAIL PROTECTED]> wrote:
> May I ask what the child process is supposed to to
> with a raw ALSA file
> descriptor? AFAICT, developers are supposed to use
> the alsa-lib API, and
> not write to FD's. So the underlying file descriptor
> looks to me like a
> mere implementation
--- Takashi Iwai <[EMAIL PROTECTED]> wrote:
> could you try the latest cvs aplay.c?
That's solved the clicking problem. I'll need to
update the ALSA on my P120 to run further checks.
That's a Friday / weekend job.
Chris
__
Do You Yahoo!?
Everythi
At 02 Feb 2003 02:52:01 +0100,
Olaf Giesbrecht wrote:
>
> > could you show /etc/asound.state for debugging.
>
> here it is:
>
> state.ICE1712 {
...
> control.5 {
> comment.access 'read write'
> comment.type BOOLEAN
> iface MIXER
>
At Wed, 5 Feb 2003 18:40:42 +0100,
Voluspa wrote:
>
>
> By deleting one test done to the ac97 codec, the es1968 driver loads (and works).
>With this I've reached the end of my debugging capabilities:
ah, thanks!
this is something what i've already seen on the kernel oss driver, but
didn't know
31 matches
Mail list logo
