Re: [linux-audio-dev] Some ALSA mixer API questions

[Clemens Ladisch]

Ross Vandegrift wrote:
> I'm a bit confused by how to get element types.  It seems like amixer
> opens the ctl device to get a mixer element's type?

All accesses to the mixer go through the ctl device.


HTH
Clemens

Re: [linux-audio-dev] ALSA performance issues?

[Clemens Ladisch]

Mario Lang wrote:
> I just tried to get sound working on a LinkSys NSLU2 (ARM) running
> Debian Etch using a USB sound card.
> 
> What I discovered I find pretty strange, and would like to know some
> more details.  Apparently, all ALSA native clients don't
> manage to play sound click-free, they actually have underruns all the
> time.  However, if I use OSS (via the snd-pcm-oss module) and set
> libao to use the oss driver, I get perfect playback with about
> 20% CPU use at maxiumum by the user-space app playing/decoding files.

Does the same happen when ALSA clients play to device "hw:0" as
opposed to the default dmix device?


Regards,
Clemens

Re: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question

[Clemens Ladisch]

Fons Adriaensen wrote:
> On Wed, Nov 08, 2006 at 05:58:40PM +0100, Clemens Ladisch wrote:
> > > In that case, how can one test if *all* pollfd for a given
> > > pcm are ready ?
> > 
> > You cannot.  The state of the file descriptors is not necessarily
> > related to the state of the PCM device (which is why this function
> > exists).
> 
> So a loop waiting for both capture and playback being ready
> could be something like (cut down to the bare minimum):
> [...]

Yes.  The various snd_pcm_poll* functions just make the descriptors look
like a single poll descriptor.  The logic should always be the same as
if it were using a single fd.


Regards,
Clemens

Re: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question

[Clemens Ladisch]

Fons Adriaensen wrote:
> On Wed, Nov 08, 2006 at 02:24:30PM +0100, Fons Adriaensen wrote:
> > Is snd_pcm_poll_descriptors_revents() more than an
> > accessor ? If it is, the name is a quite misleading. 
> 
> To answer my own question, it seems that it *is* more
> than an accessor. 
> 
> The docs leave one thing unclear. Does this call require
> an array of unsigned short int (one per pollfd), or are
> events from all pollfds combined into one revents value?

It returns one revents value for the PCM device.

> In that case, how can one test if *all* pollfd for a given
> pcm are ready ?

You cannot.  The state of the file descriptors is not necessarily
related to the state of the PCM device (which is why this function
exists).


Regards,
Clemens

Re: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)

[Clemens Ladisch]

Fons Adriaensen wrote:
> On Wed, Nov 08, 2006 at 12:20:42AM +, James Courtier-Dutton wrote:
> > The current jackd skips a step in the processing of the poll events.
> 
> Basically what happens comes down to (ignoring error
> checking and timeouts):
> 
> - The set of pollfd is poll()'ed until all are ready.

Applications must not look at ALSA's pollfds, they must use
snd_pcm_poll_descriptors_revents() instead.


Regards,
Clemens

Re: [linux-audio-dev] alsa, oss , efficiency?

[Clemens Ladisch]

lemmel wrote:
> The sound was always troncated (even with finished software such as xmms, 
> amarok),

Were there samples missing at the beginning or at the end?

> and even randomly truncated,

What do you mean with "randomly"?

What sound card/kernel version/ALSA version are you using?


Regards,
Clemens

Re: [linux-audio-dev] about MIDI timing...

[Clemens Ladisch]

Chris Cannam wrote:
> Clemens:
> > Most sound cards don't have an internal timer that could be used for
> > MIDI timing.  ALSA uses whatever timer is configured, the default for
> > this is the RTC timer.
> 
> It is?  For ALSA sequencer queues?  I thought the 
> default was system timer.

Since 1.0.11, the RTC timer is used, if available.

> Maybe it just depends on the modules you have loaded. 

Timer modules are loaded automatically.

> My impression from Rosegarden users' reports has 
> been that trying to use the ALSA sequencer with the 
> RTC timer (something I've never bothered with myself: 
> I always use a 1000Hz system timer) is a reliable way 
> to lock up your system completely, with most kernels 
> from about 2.6.13 or so onwards.

Kernels >= 2.6.15 work.  The configure script checks for older kernels.


HTH
Clemens

Re: [linux-audio-dev] about MIDI timing...

[Clemens Ladisch]

Mulyadi Santosa wrote:
> I also read that not all Linux kernel sound card driver enable the
> internal card timer, thus the software must rely on system timer.

Most sound cards don't have an internal timer that could be used for
MIDI timing.  ALSA uses whatever timer is configured, the default for
this is the RTC timer.


HTH
Clemens

Re: [linux-audio-dev] Help needed: mpg123 lives!

[Clemens Ladisch]

Nicholas J Humfrey wrote:
> I have been trying to add ALSA 0.9/1.0 API support - but have been  
> having a few problems - is anyone able to help out?

Yes.


Regards,
Clemens

Re: [linux-audio-dev] Basic MIDI question

[Clemens Ladisch]

Ari Kauppi wrote:
> On Wed, 26 Jul 2006, Jens M Andreasen wrote:
> 
> > if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF)
> 
> If you plan to receive messages from other channels than 0 you have to 
> use (runningStatus & 0xF0) instead of the full runningStatus and perhaps 
> check for (runningStaus & 0x0F) == receiveChannel..

Okay, here is my entry to the Official LAD MIDI Parser Contest 2006:

void handleByte(u8 byte)
{
/* in a driver, these static variables should go into some struct: */
static enum {
STATE_UNKNOWN, /* not a note command */
STATE_NOTE1,   /* expecting 1st data byte (note) */
STATE_NOTE2,   /* expecting 2nd data byte (velocity) */
} state = STATE_UNKNOWN;
static u8 command;
static u8 note;

if (byte >= 0xf8) /* real-time command */
;
else if (byte & 0x80) { /* status byte */
command = byte;
/* note-on or note-off? */
state = (byte & 0xf0) <= 0x90 ? STATE_NOTE1 : STATE_UNKNOWN;
} else { /* data byte */
if (state == STATE_NOTE1) {
note = byte;
state = STATE_NOTE2;
} else if (state == STATE_NOTE2) {
if ((command & 0xf0) == 0x90 && byte > 0) {
/* note on */
} else {
/* note off */
}
state = STATE_NOTE1;
}
}
}


Regards,
Clemens

Re: [linux-audio-dev] Basic MIDI question

[Clemens Ladisch]

Lee Revell wrote:
> On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote:
> > (ALSA's
> > sequencer event -> rawmidi converter uses running status by default.) 
> 
> "By default" - so it can it be disabled?  How?

snd_midi_event_no_status(), but this cannot be changed by a driver.
This setting wouldn't apply to data written directly to the rawmidi port
anyway.


Regards,
Clemens

Re: [linux-audio-dev] Basic MIDI question

[Clemens Ladisch]

Lee Revell wrote:
> I was confused because I also see these timestamps when snooping
> the MIDI output stream inside the kernel's MPU401 driver.  I guess I
> assumed that aplaymidi would deliver the events with correct timing,
> rather than passing the timestamps through.

The MIDI data at a raw MIDI port never has timestamps.  What you see are
the data bytes of the next MIDI command where the command byte itself
has been omitted because it would be identical to the last one.  (ALSA's
sequencer event -> rawmidi converter uses running status by default.)

The running status and the zero note-on velocity (see Nicolas' mail) are
the only special cases your parser has to look out for.


HTH
Clemens

Re: [linux-audio-dev] MIDI... know how to do bank/patch changes on yamaha Motif Rack?

[Clemens Ladisch]

Stephen Cameron wrote:
> The manual fails to mention what the Bank Change message is
> (probably because it is "standard MIDI stuff.")  It is 0xB0
> (or 0xBn, where n is the channel the device receives basic 
> messages on.)

Bx is the Control Change command.  The two halves of the bank number are
just two controllers, 0 and 32.

> It requires TWO bank select commands to select a bank.  One
> to set the MSB, and one to set the LSB.  You can't set them
> both with one command (which is what I was trying to do that
> didn't work.)

You can omit the command byte (called "status" in MIDI) when it is
identical to the last one, so you could use

B0 00 msb 20 lsb

This feature is called "running status".

> 0xB0 0x00 0xf3  // 0xB0 0x00 means "set bank MSB"  0xf3 is the 
> // value to set it to.

This is not a valid MIDI command.  The highest bit of each byte is used
to differentitate between command and data bytes, so data bytes must be
no greater than 127 (0x7f).

The manual should document somewhere what the MSB value for this bank
is, but it's certainly not F3.


To learn more about MIDI, have a look (or more than one) at
.


HTH
Clemens

Re: [linux-audio-dev] How to use the alsa sequencer?

[Clemens Ladisch]

Stephen Cameron wrote:
> What I'm supposed to use for the "name" parameter for snd_seq_open
> is not exactly clear.

"default"

> I've been using "hw:0,0" and it returns zero,

"default" happens to be an alias for "hw" at the moment, and the ALSA
library doesn't bother to check for superfluous parameters ...


Regards,
Clemens

Re: [linux-audio-dev] precise event timer examples (HPET?)

[Clemens Ladisch]

Alex wrote:
> Does anyone have any examples that use HPET (or any other high
> resolution event) timers?  I've built HPET support into my kernel but
> I cannot figure out how to compile the example given in the
> documentation :
> /usr/src/linux-2.6.12/Documentation/hpet.txt

/dev/hpet didn't quite work in kernels before about 2.6.15 because of
various bugs.

The example program uses a kernel header that probably isn't available
to user space programs.

And if you got it to compile, it probably wouldn't run because the third
timer is the only one available (the first two are used for the system
timer and for RTC emulation, respectively), and most BIOSes don't
initialize the third interrupt.

> I'd like to have micro-second precision and I'm wondering if there is
> a better way then polling the time of day?

When HPET is enabled, gettimeofday() uses it.
What is the output of "dmesg | grep -i hpet"?

If you want to avoid the syscall overhead, you can try to call mmap() on
/dev/hpet and read the timer directly.  In that case, you don't need to
use any header.


HTH
Clemens

Re: [linux-audio-dev] ALSA Picture

[Clemens Ladisch]

Richard Spindler wrote:
> 2006/3/24, Clemens Ladisch <[EMAIL PROTECTED]>:
> > The SUSPENDED and XRUN states can happen asynchronously, i.e., the
> > device can go into them at any time (from some other states), and the
> > next call to snd_pcm_writei() only reports them.  In this regard, they
> > are similar to the DISCONNECTED state.
> 
> Is this an issue when using this async-stuff? I think the most likely
> situation might be that it happens when you call writei.

XRUN won't happen unless the device is running, but SUSPENDED can happen
with any function that tries to access the hardware (like, e.g.,
snd_pcm_hw_params()).

> > XRUN happens not only when an over/underrun occurs but also when some
> > other error causes the device to stop (this error may be recoverable or
> > not).
> 
> What could that be?

Some drivers stop the device when a DMA error occurs (which may be a
real over/underrun when there was too much other activity on the PCI bus
so that the data could not be transferred).

The AK4114/4117 drivers put the capture device into the DRAINING state
when the sample rate of the digital input changes.


HTH
Clemens

Re: [linux-audio-dev] select() ?? before snd_pcm_writei(handle, buffer, frames);

[Clemens Ladisch]

kurmisk wrote:
> I have write my small _alsa_test_program_.  
> [C code ckunkz see below]
> It works good but now i wanna before call
> rc = snd_pcm_writei(handle, buffer, frames);
> somehow check - is sound device free for this call or not.

You could call snd_pcm_avail_update().

If you don't want the write function to block, you can set the device to
non-blocking mode, then snd_pcm_writei() will only write as much data as
can be written without waiting, or will return -EAGAIN if there isn't
free space at all.

You can use snd_pcm_poll_descriptors() to get file handle(s) for polling
(poll() is preferred over select()).


HTH
Clemens

Re: [linux-audio-dev] Alsa Problem

[Clemens Ladisch]

Lee Revell wrote:
> On Fri, 2006-03-24 at 14:09 +0100, Richard Spindler wrote:
> > I'm using snd_pcm_writei to playback some audio, however, after a
> > little time the call fails with the error: "File descriptor in bad
> > state", which I believe I cannot recover from.
> > 
> > Why does this happen, and what could I do about this?
> > 
> > cat /proc/asound/card0/pcm0p/sub0/* prints the following stuff, I
> > don't know whether this is helpful?
> > 
> > access: MMAP_INTERLEAVED 
> 
> You have set up the device for MMAP mode

I guess the actual device being used is "default" which is probably a
dmix device that uses the hardware device as a slave.  In this case, the
hardware device will continue running even when the dmix device is in a
bad state.

Richard, was is the state of your device?  (See snd_pcm_dump() or
snd_pcm_state().)


Regards,
Clemens

Re: [linux-audio-dev] ALSA Picture

[Clemens Ladisch]

Richard Spindler wrote:
> on my quest to understand the ALSA API, I created a little Image to
> get an overview about the various states and how they relate to each
> other.
> 
> http://propirate.net/oracle/bilder/ALSA.png

Cool, the first complete page of The ALSA Programming Manual!

Now we only need somebody to write the remaining 999 pages ... ;-)

> Hopefully I got everyting right, can you have a look at this image and
> tell me whether this is correct?

snd_pcm_hw_params() goes into the SETUP state and then calls
snd_pcm_prepare(); I don't know how to display this in a picture. :)

You probably want an arrow from snd_pcm_writei() to RUNNING.

The SUSPENDED and XRUN states can happen asynchronously, i.e., the
device can go into them at any time (from some other states), and the
next call to snd_pcm_writei() only reports them.  In this regard, they
are similar to the DISCONNECTED state.

XRUN happens not only when an over/underrun occurs but also when some
other error causes the device to stop (this error may be recoverable or
not).


Regards,
Clemens

Re: [linux-audio-dev] What is currently the best USB audio interface for Linux?

[Clemens Ladisch]

ico wrote:
> I am in the process of considering a portable USB audio interface. Having 
> checked the alsa matrix, I am a bit at a loss what may be the best option.

Have a look at ,
too.

> 2) Preferrably USB 2.0 capable

The only supported USB 2.0 device is the Creative Audigy 2 NX, and
high speed capturing is broken in all kernels before 2.6.17.
(But who cares about audio when the remote control works ...  ;-)

> 4) High fidelity (higher the better)

Okay, forget USB 2.0 ...

> 5) More inputs/outputs, the better

USB 1.x bandwidth is quite limited.  It's possible to transfer eight
channels of 16-bit audio at 48 kHz, but full duplex 24 bit stereo at
96 kHz is not possible.

> 6) Preferrably has some preamp inputs
> 7) Obviously must be supported in Linux/Alsa
> 8) Price not an issue

Have a look at the Edirol devices (except the UA-1000 or UA-101).


HTH
Clemens

Re: [linux-audio-dev] Writing PCM to left and right channel sperately?

[Clemens Ladisch]

Tobias Scharnberg wrote:
> I need to use the left and the right audio channel seperately.

If you're using the ALSA library, you can use the following definitions
in /etc/asound.conf or ~/.asoundrc to get two independent virtual
devices:

pcm.left {
type plug
slave.pcm {
type dshare
ipc_key 12345
slave.pcm "hw:0,0"
slave.channels 2
bindings {
0 0
}
}
}

pcm.right {
type plug
slave.pcm {
type dshare
ipc_key 12345
slave.pcm "hw:0,0"
slave.channels 2
bindings {
0 1
}
}
}


HTH
Clemens

Re: [linux-audio-dev] Reliability of SPDIF sync w/ onboard audio?

[Clemens Ladisch]

[EMAIL PROTECTED] wrote:
> Ok, given a pair of commodity Linux PC's with cheapo onboard audio
> codecs capable of SPDIF input and output, assuming I sent identical
> input signals into both machines and didn't perform any processing in
> the middle, could I reasonably expect the output signals to be
> synchronized, or should I expect unpleasant phasing / delay effects
> when listening to both channels simultaneously as a result of the
> inherently flakey consumer-grade codecs?

Onboard codecs do not support synchronizing to an external signal.  The
output frequency will always be determined by their own sample clock.


Regards,
Clemens

Re: [linux-audio-dev] Fwd: OT -- USB History

[Clemens Ladisch]

Christoph Eckert wrote:
> Some of us (including me) would like to see a USB 2.0 breakout box which 
> grants more than 2x2 channels while using a standard USB 2.0 protocol.

There is the SB Audigy 2 NX with 8+2 channels.
(You didn't mention any quality constraints.  ;-)


Clemens

Re: [linux-audio-dev] Hello & Help

[Clemens Ladisch]

Vaughan Famularo wrote:
> The Ux16 shows up in the qjackctrl midi connections gui. BUT nothing
> appears to be triggered by my exterior keyboard.

Do you get anything with "amidi --dump -p ..."?
(see "amidi -l" for a list of port names)


Regards,
Clemens

Re: [linux-audio-dev] configuring ALSA support in linux 2.6.11

[Clemens Ladisch]

chandrasheakhar singh wrote:
> I think we are right, but as far as ALSA is concerned if i'm correct,  it
> does talk about lowest audio
> driver, it emulates oss to access lowest audio driver, if this is the case
> then ALSA should work with existing audio driver.

ALSA can emulate the OSS API for user-space applications, but all its drivers
must use its own internal API.

> If you have something to share about how to port ALSA for this target ,
> please let me know.

Have a look at Documentation/sound/alsa/DocBook/writing-an-alsa-driver.


HTH
Clemens

Re: [linux-audio-dev] configuring ALSA support in linux 2.6.11

[Clemens Ladisch]

chandrasheakhar singh wrote:
> Do you suggest  me anything to test or verify in driver as default
> config file for this target (omap_h4_2420_defconfig) does not have
> ALSA configuration macro to configure.
> 
> >>CONFIG_SOUND_OMAP=y
> >>CONFIG_SOUND_TSC2101 =y

It looks as if these are OSS drivers.  You cannot use those with ALSA
unless you've ported them to use the ALSA API.


HTH
Clemens

Re: [linux-audio-dev] configuring ALSA support in linux 2.6.11

[Clemens Ladisch]

chandrasheakhar singh wrote:
> I wanted to configure ALSA for omap 2420 (h4) in linux 2.6.11.
>
> CONFIG_SOUND=y
> CONFIG_SND=y
> CONFIG_SND_PCM=y
> CONFIG_SND_OSSEMUL=y
> CONFIG_SND_MIXER_OSS=y
> CONFIG_SND_PCM_OSS=y
> CONFIG_SOUND_OMAP=y
> CONFIG_SOUND_TSC2101 =y
>
> After booting the kernel i can only see the following :
>
> dev/snd/mixer
> dev/snd/mixer

Are there really two files with the same name?

> dev/snd/control0

This should be controlC0.

What are the actual contents of /dev/snd/?

> but where is snd/snd which will emulate oss dsp ?

OSS PCM emulation would be /dev/dsp, but only if the driver actually has
a PCM device.  Yours hasn't (there would be an ALSA device, /dev/snd/pcmC0D0p).

> Can you tell me where i am wrong 

Somewhere in the driver source code, which you didn't show.


HTH
Clemens

Re: [linux-audio-dev] ALSA MIDI Sync

[Clemens Ladisch]

Peter Brinkmann wrote:
> I'm trying to figure out how to build an ALSA MIDI sequencer that'll
> sync with other sequencers. I've looked around but didn't see any
> recent information.
> So, my question is, what's the recommended way of synchronizing two
> MIDI sequencers these days, using ALSA? Is there any protocol (MTC,
> MMC...) that you would recommend so as to be compatible with a large
> number of other software packages?

ALSA itself doesn't support any synchronization protocol; the only
possible timer source is some hardware timer interrupt.
It is possible to adjust the queue tempo relative to the timer
interrupt frequency with snd_seq_queue_tempo_set_skew().

> Pointers to sample implementations of MIDI sync with ALSA would be
> great.

AFAICS Ardour supports MTC.


HTH
Clemens

Re: [linux-audio-dev] ALSA configuration help and building help

[Clemens Ladisch]

chandrasheakhar singh wrote:
> After executing the kernel on OMAP 2420 I got the following devices for
> ALSA in /dev/snd [controlC0  midiC0D0  midiC0D1  midiC0D2  midiC0D3  seq
> timer] but the snd
> device which can play the PCM data is not coming up.

Looks like a bug in the driver (you didn't tell us which one).


HTH
Clemens

Re: [linux-audio-dev] [linux-audio-user] External audio interface (edirol FA/UA-101)

[Clemens Ladisch]

Paul Davis wrote:
> 8 channels across USB? forget it. USB can stretch to about 4 channels
> before things start to fall apart.

An Audigy 2 NX manages eight channels just fine, even in USB 1.1 mode
(but then with no more than 16 bits at 48 kHz, and without capturing).

> YMMV, but this is what i've seen in many win/mac audio forums.

Linux rocks!  ;-)


Regards,
Clemens

Re: [linux-audio-dev] USB-MIDI Transfer rate

[Clemens Ladisch]

Jens M Andreasen wrote:
> I am running into troubles here. After reboot, the usb-midi goes
> haywire!? And I have not even done any changes to the system yet ...
>
> At first, I reboot with the usb device off and then have a peek:
>
> $ ls /dev/midi*
> /dev/midi1
>
> $ amidi -l
> DeviceName
> hw:1,0MPU-401 MIDI 1-0
>
> .. which looks as expected. But then turning the device on gets weired:
>
> $ amidi -l
> DeviceName
> hw:1,0MPU-401 MIDI 1-0
>
> ls /dev/midi*
> /dev/midi  /dev/midi1  /dev/midi2  /dev/midi3
>
> .. which is no good. The /dev/midi* devices are too many and not
> working.

It seems the usb-midi driver grabbed the device first.  Disable it in
the kernel configuration, or put the line

usb-midi

into the /etc/hotplug/blacklist file.


HTH
Clemens

Re: [linux-audio-dev] USB-MIDI Transfer rate

[Clemens Ladisch]

Jens M Andreasen wrote:
> On Fri, 2005-09-16 at 17:10 +0200, Clemens Ladisch wrote:
> > Jens M Andreasen wrote:
> > > Are you absolutely sure that it is not possible to increase the thruput?
> >
> > Try changing the line:
> >
> > ep->max_transfer = usb_maxpacket(umidi->chip->dev, pipe, 1);
> >
> > in the snd_usbmidi_out_endpoint_create function in usbmidi.c to:
> >
> > ep->max_transfer = 512;
>
> This will change all ports, no? Both internal as well as external?

Yes.  The MIDI data for all ports is multiplexed through the two
(output+input) endpoints.


Regards,
Clemens

Re: [linux-audio-dev] USB-MIDI Transfer rate

[Clemens Ladisch]

Jens M Andreasen wrote:
> On Fri, 2005-09-16 at 09:52 +0200, Clemens Ladisch wrote:
> > > The MIDI-USB device also have a control channel without any endpoints
> > > (without any physical midi-jacks.) Again only as far as I have
> > > understood; the control channel is not a MidiStream and should therefore
> > > be able to accept a significantly higher transfer rate than the physical
> > > MidiStreams.
> >
> > Control transfers always involve an answer sent by the other device,
> > and multiple control transfers cannot be sent in parallel, so the data
> > rate would be rather low.
>
> In the specific case, I get that the transfer rate on the control equals
> a normal midi stream. The data sent to the control is normal midi data.

Are you speaking about the device's control pipe or about a MIDI port
that happens to be labeled "control"?  The former _cannot_ be used to
send MIDI data, and the latter is just a standard USB MIDI stream.

> Are you absolutely sure that it is not possible to increase the thruput?

Try changing the line:

ep->max_transfer = usb_maxpacket(umidi->chip->dev, pipe, 1);

in the snd_usbmidi_out_endpoint_create function in usbmidi.c to:

ep->max_transfer = 512;

or even bigger values.  This should result in more than one packet per
frame.


It would be interesting to know what the maximum data rate is.


Regards,
Clemens

Re: [linux-audio-dev] USB-MIDI Transfer rate

[Clemens Ladisch]

Jens M Andreasen wrote:
> I am currently working on digesting the USB-MIDI Class Definition ...
>
>  http://www.usb.org/developers/devclass_docs/midi10.pdf
>
> As I understand, you can have up to 16 USB MidiStreams (MS), each equal
> to a physical midi-cable (and each "cable" having 16 virtual
> midi-channels.)

Yes.

> There is a bandwith limit of one 3-byte midievent/ms

There isn't.  Each USB MIDI packet uses 4 bytes, and the maximum
packet size of a USB MIDI endpoint is usually between 16 and 64 bytes.

It would be possible to send more than one USB packet per millisecond
(bulk transfers can get very near to the theoretical maximum USB
rate), but the snd-usb-audio driver doesn't bother to do this for
MIDI.

If the MIDI data doesn't go to a physical MIDI port, the sustained
bandwidth is indeed much higher than 3 KB/s.

> The MIDI-USB device also have a control channel without any endpoints
> (without any physical midi-jacks.) Again only as far as I have
> understood; the control channel is not a MidiStream and should therefore
> be able to accept a significantly higher transfer rate than the physical
> MidiStreams.

Control transfers always involve an answer sent by the other device,
and multiple control transfers cannot be sent in parallel, so the data
rate would be rather low.

> Question: How do I determine the max transfer rate for the control
> channel (bInterFaceSubClass == 1) as apposed to the physical midi-outs
> (bInterFaceSubClass == 3) ?+

This depends heavily on the device firmware (the answers to control
transfers can be delayed for several milliseconds).

> This is for setting LEDs partially lid for more than one parameter, by
> pulsewidth-modulation over USB-MIDI.

How much success do you have with this?  I guess it would be very hard
to synchronize the MIDI commands to the USB frame clock.


Regards,
Clemens

Re: [linux-audio-dev] USB: Is a CLASS_INTERFACE request a kind of control transfer ?

[Clemens Ladisch]

Jan Holst Jensen wrote:
> I am (still) trying to implement a control panel
> feature for the U2A USB sound card.
>
> Now, half of the URBs sent to the device are
> CONTROL_TRANSFER blocks, but the other half are marked
> as CLASS_INTERFACE in the SnoopyPro logs. See a
> typical example below.

SnoopyPro doesn't label all packets correctly.  It seems the
bmRequestType field hasn't yet been filled when the 'down' request is
logged, so you have to look at the corresponding 'up' data.

> I have googled the net and searched the USB specs
> without getting much wiser as to what a
> CLASS_INTERFACE request is and does.

"CLASS" means that the meaning of the bRequest field is class-specific
-- in this case, defined in the USB audio specification.

To determine what the other fields mean, get the unit ID from the
upper byte of the wIndex field (sixth byte in the setup packet),
search for the unit in the descriptors, and then look up that unit
type in the USB audio spec.

> Can I send it using CONTROL_TRANSFER URBs or is yet another
> extension of the alsa driver necessary ?

With USB audio devices, all transfers (except the audio data itself)
are control transfers.

> SetupPacket:
> : 21 01 00 01 00 04 01 00

bRequestType: 0x21CLASS_INTERFACE, out
bRequest: 0x01SET_CUR
wValue:   0x0100  control/channel? #1 (MSB) of this unit
wIndex:   0x0400  interface #0 (LSB), unit #4 (MSB)
wLength:  0x0001

I guess that unit 4 is a Selector Unit, because most other types would
require a two-byte buffer.


HTH
Clemens

Re: [linux-audio-dev] Alsa Sequencer Raw MIDI Data

[Clemens Ladisch]

Dirk Jagdmann wrote:
> I'm currently developing an application which should be controlled via
> MIDI. I'd like to use the Alsa Sequencer API, so I can use aconnect and
> friends to connect my app to other apps and MIDI hardware. However I
> like to get access and send the raw MIDI stream.

The whole point of the sequencer API is to exchange (already parsed)
messages instead of raw MIDI data, but the ALSA library contains a
helper object to convert between them:
http://alsa-project.org/alsa-doc/alsa-lib/group___m_i_d_i___event.html


HTH
Clemens

Re: [linux-audio-dev] Marian soundcards

[Clemens Ladisch]

Marije Baalman wrote:
> Unfortunately, the most interesting card they have (the UCON CX) is not
> amongst those for which they supply info...

It's an USB device.  With luck, it's already supported by
snd-usb-audio.


Regards,
Clemens

Re: [linux-audio-dev] Libs for reading/writing midis

[Clemens Ladisch]

Jens M Andreasen wrote:
> On Tue, 2005-08-09 at 15:31 +0200, Clemens Ladisch wrote:
> > [...] when going from the graveyard to the tomb, the
> > music is blended to another track that plays the same melody with
> > different instruments for a more "closed" feeling.
>
> Focus on the graveyard: Is the transition described in type 2, or is it
> programmed by the game designer?

Type 2 files contain just a bunch of tracks; the SMF specification
doesn't include any means to describe how these tracks are related,
except for non-standard sequencer-specific meta events which you have
to define for yourself.  This is why type 2 files cannot be used to
interchange MIDI data.


Regards,
Clemens

Re: [linux-audio-dev] Libs for reading/writing midis

[Clemens Ladisch]

Jens M Andreasen wrote:
> What is type 2 ?

Type 2 files contain several related tracks, like type 1, but instead
of being played in parallel, these tracks are to be used in some
unspecified way.

For example, the background music in Monkey Island 2 uses one type 2
file for each room where the other tracks contain endings/transitions
that are spliced into the main track when the figure leaves a room at
a specific time; or, when going from the graveyard to the tomb, the
music is blended to another track that plays the same melody with
different instruments for a more "closed" feeling.


Regards,
Clemens

Re: [linux-audio-dev] ALSA MIDI latency correction

[Clemens Ladisch]

Peter Brinkmann wrote:
> I have a sequencer application that has several MIDI output ports,
> each connected to some device that accepts MIDI input. Those
> devices may have vastly different latencies ... but of course I
> don't want to hear a time lag between those devices.
>
> I'm currently scheduling all my events through one queue (is that the
> recommended method? I've been wondering whether it would make more sense
> to have, say, one queue per output port, but I don't see how this would
> help),

Using multiple queues doesn't make sense except when you wanted to use
different timer interrupts for them.

> and the only solution I have been able to think of is to explicitly
> schedule events for faster devices at a later time. This is clumsy, and
> it's exacerbated by the fact that I'd like to schedule events in terms of
> ticks rather than milliseconds. Since latencies are usually measured in
> milliseconds, that means I have to convert them to ticks, considering
> the current tempo of the queue. There's gotta be a better way.
>
> Ideally, there are two things I'd like to do:
> 1. Assign a delay dt to each output port, so that an event scheduled
> at time t0 will be sent at time t0+dt. Like this, I could compute the
> maximum latency of all my devices, and the output port attached to a
> device would get a delay of (max latency - latency of device), so
> that everything would be in sync.

This would just move the ms-to-tick conversion into the ALSA
sequencer.

> 2. Automatically determine the latencies of the devices I'm talking
> to. In theory, this should be possible. For instance, if timidity is
> connected to jack, it could get jack's current latency, add its own
> latency, and report the result. Is this science fiction?

This doesn't help with external hardware synthesizers; you'd have to
measure how soon after a note-on command its analog output shows a
signal.


Regards,
Clemens

Re: [linux-audio-dev] HOw to create an ALSA out port

[Clemens Ladisch]

Jens M Andreasen wrote:
>   int err = snd_rawmidi_open(/*in*/NULL,/*out*/&handle_out,
>device,0);
>
> The code above will wait forever if the device is already taken.
> Opening the device with SND_RAWMIDI_NONBLOCK as last argument will get
> you past that point, but then the write operation may fail (returning
> negative) or return less bytes than you asked for to be written.

You can open the device with SND_RAWMIDI_NONBLOCK and then set it to
blocking mode with "snd_rawmidi_nonblock(handle_out, 0);".


HTH
Clemens

Re: [linux-audio-dev] HOw to create an ALSA out port

[Clemens Ladisch]

Christoph Eckert wrote:
> I only need to write sysex data which are kept in a character
> array. Is there a possibility to easily
>
> * connect to a certain port of a device (the Midisport control
> port)
> * send the contents of the array to this port
> * close the port

This is pretty much exactly what amidi does.  The writing itself can
be done trivially with snd_rawmidi_open/snd_rawmidi_write/
snd_rawmidi_close.  To get the device name of the control port, you
have to enumerate the MIDI ports; see the device_list function.


HTH
Clemens

Re: [linux-audio-dev] best soundcard revisited

[Clemens Ladisch]

Aaron wrote:
> I plan to have all the computers dual booting lin/win and want the
> best quality sound card I can get that will run on both lin and win
> with the least trouble and the most bang for the buck.
>
> I don't need multitrack recording necessicarily.

And what _do_ you need?
Neither "best quality" nor "bang" are very specific.  ;-)

Stereo playback?  5.1 playback?  Stereo recording?  Mic and/or Line
input?  SPDIF input and/or output?  16 or 24 bits?  48 or 96 kHz?
MIDI?  ..


Regards,
Clemens

[linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

[Clemens Ladisch]

Christoph Eckert wrote:
> well, I have written a small login script which catches the
> ALSA ID of my USB card and starts JACK on top of it each time
> I login. This is because I use three USB devices and I didn't
> manage to index them correctly to make them appear in the
> same order each day.

If those devices aren't the same model, you can use the vid/pid
options of the snd-usb-audio driver to force them to have a specific
index.

For example, my three USB audio devices have to following vendor/
product IDs:

0582:0007 Roland SC-8820
0582:0018 Edirol UA-1A
041e:3020 SB Audigy 2 NX

I use the following options to put them at index 4, 3, and 7,
respectively:

options snd-usb-audio index=3,4,7 pid=0x0018,0x0007,0x3020


HTH
Clemens

Re: [linux-audio-dev] Compiling ALSA. Was: Sending USB msgs to sound card...

[Clemens Ladisch]

Jan Holst Jensen wrote:
> Hmmm... I have checked out alsa via anonymous CVS from
> sourceforge. Can't get it to compile - it misses a
> ./configure script when running "./build config".

Run the cvscompile script, or see the INSTALL file.

The patch should work with the 1.0.9b release, too.


HTH
Clemens

Re: [linux-audio-dev] Two / Three HDSPM Cards?

[Clemens Ladisch]

Audio Developer wrote:
>   bindings.112.slave b;
>   bindings.112.channel 56;

This is the 113th channel.

>  pcm.hdspm_112 {
>   type multi;
>   slaves.a.pcm hdspm_0;
>   slaves.a.channels 56;
>   slaves.b.pcm hdspm_1;
>   slaves.b.channels 56;
>   bindings.0.slave a;
>   bindings.0.channel 0;
>   bindings.1.slave a;
>   bindings.1.channel 1;
>   ...

The same definition could be written in the following form:

pcm.hdspm_112 {
type multi
slaves.a {
pcm hdspm_0
channels 56
}
slaves.b {
pcm hdspm_1
channels 56
}
bindings [
{ slave a channel  0 }
{ slave a channel  1 }
{ slave a channel  2 }
...
{ slave a channel 55 }
{ slave b channel  0 }
...
{ slave b channel 55 }
]
}


HTH
Clemens

Re: [linux-audio-dev] Sending USB msgs to sound card through snd_usb_audio driver - how ?

[Clemens Ladisch]

Jan Holst Jensen wrote:
> --- Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> > > Are there any standard ioctl() calls in the
> >
> > No, but this would be a very good idea for testing
> > purposes.  I'll add a hwdep device for this.
>
> Great. Looking forward to that. But until then, my
> best shot is hacking the driver I guess... ?

This _is_ hacking the driver.  :-)

> Any idea what happens in Windows ? Doesn't seem like
> the device is locked by the driver in that OS (?).

It is, but usually the driver provides ioctls to allow applications to
change some settings.


The patch adds an hwdep device that provides a USBDEVFS_CONTROL ioctl
that should work identical to that from , except
that you need root privileges to use it.

The patch is against the CVS version of ALSA.  Both the driver and
alsa-lib need to be recompiled.

To access the device, use snd_hwdep_open() and snd_hwdep_ioctl(). The
device name is "hw:X,1" where X is the card number.


HTH
Clemens


Index: alsa/alsa-kernel/include/asound.h
===
--- alsa.orig/alsa-kernel/include/asound.h  2005-05-17 10:04:16.0 
+0200
+++ alsa/alsa-kernel/include/asound.h   2005-06-08 22:30:47.0 +0200
@@ -114,9 +114,10 @@ enum sndrv_hwdep_iface {
SNDRV_HWDEP_IFACE_USX2Y_PCM,/* Tascam US122, US224 & US428 rawusb 
pcm */
SNDRV_HWDEP_IFACE_PCXHR,/* Digigram PCXHR */
SNDRV_HWDEP_IFACE_SB_RC,/* SB Extigy/Audigy2NX remote control */
+   SNDRV_HWDEP_IFACE_USB_CTRL, /* USB control transfers */
 
/* Don't forget to change the following: */
-   SNDRV_HWDEP_IFACE_LAST = SNDRV_HWDEP_IFACE_SB_RC
+   SNDRV_HWDEP_IFACE_LAST = SNDRV_HWDEP_IFACE_USB_CTRL,
 };
 
 struct sndrv_hwdep_info {
Index: alsa/alsa-lib/include/sound/asound.h
===
--- alsa.orig/alsa-lib/include/sound/asound.h   2005-05-20 17:15:54.0 
+0200
+++ alsa/alsa-lib/include/sound/asound.h2005-06-08 22:34:12.0 
+0200
@@ -112,9 +112,10 @@ enum sndrv_hwdep_iface {
SNDRV_HWDEP_IFACE_USX2Y_PCM,/* Tascam US122, US224 & US428 rawusb 
pcm */
SNDRV_HWDEP_IFACE_PCXHR,/* Digigram PCXHR */
SNDRV_HWDEP_IFACE_SB_RC,/* SB Extigy/Audigy2NX remote control */
+   SNDRV_HWDEP_IFACE_USB_CTRL, /* USB control transfers */
 
/* Don't forget to change the following: */
-   SNDRV_HWDEP_IFACE_LAST = SNDRV_HWDEP_IFACE_SB_RC
+   SNDRV_HWDEP_IFACE_LAST = SNDRV_HWDEP_IFACE_USB_CTRL
 };
 
 struct sndrv_hwdep_info {
Index: alsa/alsa-lib/include/hwdep.h
===
--- alsa.orig/alsa-lib/include/hwdep.h  2005-04-29 17:26:40.0 +0200
+++ alsa/alsa-lib/include/hwdep.h   2005-06-08 22:37:08.0 +0200
@@ -68,8 +68,9 @@ typedef enum _snd_hwdep_iface {
SND_HWDEP_IFACE_USX2Y_PCM,  /**< Tascam US122, US224 & US428 raw 
USB PCM */
SND_HWDEP_IFACE_PCXHR,  /**< Digigram PCXHR */
SND_HWDEP_IFACE_SB_RC,  /**< SB Extigy/Audigy2NX remote control 
*/
+   SND_HWDEP_IFACE_USB_CTRL,   /**< USB control transfers */
 
-   SND_HWDEP_IFACE_LAST = SND_HWDEP_IFACE_SB_RC  /**< last known hwdep 
interface */
+   SND_HWDEP_IFACE_LAST = SND_HWDEP_IFACE_USB_CTRL /**< last known hwdep 
interface */
 } snd_hwdep_iface_t;
 
 /** open for reading */
Index: alsa/alsa-kernel/usb/usbaudio.c
===
--- alsa.orig/alsa-kernel/usb/usbaudio.c2005-05-31 18:13:22.0 
+0200
+++ alsa/alsa-kernel/usb/usbaudio.c 2005-06-08 23:31:31.0 +0200
@@ -45,11 +45,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "usbaudio.h"
@@ -3012,6 +3014,69 @@ static void snd_usb_audio_create_proc(sn
snd_info_set_text_ops(entry, chip, 1024, proc_audio_usbid_read);
 }
 
+/* hwdep interface */
+static int snd_usb_audio_hwdep_open(snd_hwdep_t *hwdep, struct file *file)
+{
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+   return 0;
+}
+
+static int snd_usb_audio_hwdep_ioctl(snd_hwdep_t *hwdep, struct file *file,
+unsigned int cmd, unsigned long arg)
+{
+   snd_usb_audio_t *chip = hwdep->private_data;
+   struct usbdevfs_ctrltransfer ctrl;
+   void *buffer;
+   int ret;
+
+   if (cmd != USBDEVFS_CONTROL)
+   return -ENOTTY;
+   if (copy_from_user(&ctrl, (void __user *)arg, sizeof(ctrl)))
+   return -EFAULT;
+   if (ctrl.wLength > PAGE_SIZE)
+   return -EINVAL;
+   if (!(buffer = (void *)__get_free_page(GFP_KERNEL)))
+   

Re: [linux-audio-dev] Sending USB msgs to sound card through snd_usb_audio driver - how ?

[Clemens Ladisch]

Jan Holst Jensen wrote:
> I am trying to control the settings of my EgoSys U2A
> sound card by sending it the same commands that I can
> see being sent to it when I am using the Windows U2A
> control panel.

What kind of messages are these?

> Are there any standard ioctl() calls in the
> snd_usb_audio driver that allows me to send messages
> to a USB interface,

No, but this would be a very good idea for testing purposes.  I'll add
a hwdep device for this.


Regards,
Clemens

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Clemens Ladisch]

Tim Goetze wrote:

> [Clemens Ladisch]
>
> > You mean you want to omit \n and the quotes?  That was always invalid
> > in both C and C++.
>
> Makes me wonder how come it used to compile cleanly then. Now please
> don't tell me "it's a gcc extension so it is evil"

It's a gcc extension so^H^Hfor compatibility with some old Unix
compilers that accidentally allowed it.  AFAIK it was dropped from g++
but not gcc because those old compilers didn't know about C++ anyway.

> because __asm__ is already kissing portability goodbye.

This issue is at a lower level, i.e., how to parse string literals.


Regards,
Clemens

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Clemens Ladisch]

Tim Goetze wrote:
> [Clemens Ladisch]
> > Tim Goetze wrote:
> >> Enter gcc version 3, which drops multi-line inline assembly support.
> >
> > The following compiles fine with gcc 3.3.3:
> >
> >__asm__ ("nop\n"
> > "nop\n");
>
> May compile fine, but like this a 100-line __asm__ goes well beyond my
> pain threshold when it comes to readability and maintainability.

You mean you want to omit \n and the quotes?  That was always invalid
in both C and C++.

> > If your external functions use the correct type (i.e., a pointer to
> > the base type), the compiler will automatically cast class pointers in
> > the correct way.  Otherwise, you have to cast to the base type
> > yourself whenever you 'export' a pointer.
>
> Believe me I have tried to come up with sensible solutions but there's
> quite a lot more to it than just fixing a few thousand pointer casts.
>
> Basically, you can't rectify the problem because the basic Python
> Object type (from which my types are derived) is actually at a fixed
> offset into a Python garbage-collected structure.

I assumed your objects should just be accessed from Python, but it's
of course different if they are to be managed by Python.

You could introduce an additional layer of indirection:  hold a
separate C++ object with a pointer from the Python-managed object.

> The following is OK for an older g++:
>
> void
> Descriptor::setup()
> {
>UniqueID = 1794;
>...
> }
>
> but g++ since 4.0 wants this instead:
>
> template <> void
> Descriptor::setup()
> {
>...
> }
>
> I cannot for the life of me imagine a good reason why "template <>"
> should be necessary.

It's needed because
A) the standard says so;
B) Descriptor is still a template, even if all template parameters
   happen to be specialized.

> "setup()" was never declared as a template, let alone one with an
> empty template parameter.

I guess you don't want to hear it, but if setup() was declared as a
template, you would have to write something like this:

template <> template  void
Descriptor::setup()
{ ... }

> If this is indeed prescribed by the language standard, I'll have a
> very, very hard time getting over it.

For completely specialized templates, you can avoid the "template<>"
stuff like this:

typedef Descriptor Amp4Descriptor; // no "template" needed here

void Amp4Descriptor::setup() {...}

> It may not look like much but you have to understand that to me
> coding is also an exercise in aesthetics.

"aesthetics" is not a keyword in C++.  ;-)


Regards,
Clemens

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Clemens Ladisch]

Tim Goetze wrote:
> Enter gcc version 3, which drops multi-line inline assembly support.

The following compiles fine with gcc 3.3.3:

void f()
{
__asm__ ("nop\n"
 "nop\n");
}

> Enter gcc version 3, moving the vtable member to memory offset 0 of a
> derived type even if the base type is in C which doesn't know about
> vtables.

There are no memory layout guarantees for non-POD types.

If your external functions use the correct type (i.e., a pointer to
the base type), the compiler will automatically cast class pointers in
the correct way.  Otherwise, you have to cast to the base type
yourself whenever you 'export' a pointer.

> Enter gcc version 4, which requires the templated types' constructor
> code be rewritten in the most nonsensical, misleading and ugly fashion
> possibly imaginable this side of Hungary and Redmond, WA, according to
> our (now not so very young anymore) hero.

Could you show some details?  Probably the old code wasn't quite
correct according to The Standard(TM).


Regards,
Clemens

Re: [linux-audio-dev] ALSA Sequencer API - How to Receive Events?

[Clemens Ladisch]

Sean Don wrote:
> 1) I don't have a hardware sequencer; so, I use
> timidity as an ALSA sequencer, then pmidi a player...
>
> timidity -iA -B8,8 -Os &
> pmidi -p 128:0 
>
> 2) That plays fine, but how to tap into the events
> pmidi is sending to 128:0?

The events are sent to Timidity (128:0), not to your program.

And you wouldn't want other programs to be able to intercept events
not directed to them, because those events could contain sensitive
data.  Uh, yeah.  ;-)

Anyway: load snd-seq-dummy, connect a through port to both Timidity
and your program, then play to the through port.


HTH
Clemens

Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?

[Clemens Ladisch]

Jay Vaughan wrote:
> i'd like to ask members of LAD to report on their experiences with
> using professional MIDI interfaces, such as (for example) the Motu
> MTP AV, Digidesign MIDEX-8, etc?
>
> what is the 'easiest' MIDI interface to get working under the average
> Linux kernel?

The 8x8 interfaces from ESI (Miditerminal M8U), Edirol (UM-880),
M-Audio (Midisport 8x8), and Emagic (Unitor8, AMT8) work with ALSA;
the Emagic ones require the new ALSA 1.0.9.  The Midisport is the only
one that isn't easy because it needs a separate firmware loader to be
installed manually.

> for me so far, MidiShare seems to offer the most direct and usable
> approach .. while ALSA is wraught with complexity and dependencies
> which often seem out of control.

Under Linux, MidiShare depends on ALSA anyway ...  :-)

The problem is more that ALSA isn't very well documented.
Have a look at the programs in alsa-utils/seq/.


Regards,
Clemens

Re: [linux-audio-dev] deblocking snd_seq_event_input()

[Clemens Ladisch]

Jens M Andreasen wrote:
> On Sun, 2005-05-08 at 12:50 +0200, Fons Adriaensen wrote:
> > But this is besides the point. In my original problem it is not the 
> > intention
> > to terminate the thread - just to force the snd_seq_event_input() to return.
> > The thread could well close the handle, open a new one and continue normal
> > operation. The simplest solution is probably to send some fake event to the
> > midi port.

Yes, you can use a user-defined event for this.

> Perhaps poll() with a shortish timeout? Wake up now and then and do some
> housekeeping.

It would be better to use poll with two objects: the sequencer, and
some pipe or something like that used for communication between
threads.


Regards,
Clemens

Re: [linux-audio-dev] deblocking snd_seq_event_input()

[Clemens Ladisch]

Fons Adriaensen wrote:
> Shouldn't a call that waits on fd return with an error code when
> that fd is closed ?

The ALSA library isn't thread safe.

> Since snd_seq_event_input() probably uses poll() internally, why
> doesn't it test for POLLERR,-HUP,-NVAL ?

It just calls read().


Regards,
Clemens

Re: [linux-audio-dev] deblocking snd_seq_event_input()

[Clemens Ladisch]

Fons Adriaensen wrote:
> Is there a simple (i.e. simpler than getting the pollfd and using them)
> to force snd_seq_event_input() in blocking mode to return, so the the
> calling thread can close the handle and cleanup ?

You could try to send this thread a signal, but I don't know how well
signals and threads work together.

Otherwise, if you want to wait for an event other than "sequencer
event received", you must use poll.


HTH
Clemens

Re: [linux-audio-dev] jitter on USB audio

[Clemens Ladisch]

Alfons Adriaensen wrote:
> At 48 kHz, USB delivers and consumes audio samples in chunks of 48 frames.

Depends.  This is true for playback (for most devices), but recording
is done with whatever chunk sizes the device delivers.  This may be
close to 48 samples per USB frame if the device synchronizes its
internal clock to the USB frame clock.

> When using ALSA's mmap inmterface,

... or the read/write interface, there's no difference, ...

> these will repackaged to the requested period size.

Yes.  The driver will pick a period size that is bigger than one USB
request buffer (URB), and will issue an 'interrupt' whenever a period
has been completely filled.

> So one would expect to see a jitter with a range of 1 ms in the
> wakeup times of a thread waiting on this interface. For example
> for p = 256 the real periods will be 6ms, 5ms, 5ms, 6ms, 5ms, 5ms,
> ... for an average period of 5.333 ms.
>
> In practice, when using snd-usb-audio, the jitter range is close to 4 ms.
> Why is this, and can something be done about it ?

A USB request can be made for more than one USB frame.  By default,
the driver uses about four packets per URB which means that the driver
gets notified by the USB controller in 4 ms intervals.

This can be changed with the nrpacks parameter of the snd-usb-audio
module.

Have a look at /proc/asound/cardX/stream0 while running; the numbers
in brackets after "URBs" are the number of packets per URB, which
should be the same as the jitter in ms.


HTH
Clemens

Re: [linux-audio-dev] Extreme (midi) omni-mode

[Clemens Ladisch]

Jens M Andreasen wrote:
> Say you had an external single channel midi module, and it wakes up in
> omni-mode (all channels are equal), you will ofcourse expect it to make
> a sound, no matter the settings on your sending keyboard.
>
> Now, suppose the module is multi-timbral?
> What is the expected result?

Multi-timbral modules typically don't support omni mode.

> 16 different sounds layered?. How?
> Prior art?

GS and XG devices (and probably most other modules, too) have SysEx
commands to reassign parts (or whatever they're called) to any MIDI
channel.


Regards,
Clemens

Re: [linux-audio-dev] XITEL INPORT

[Clemens Ladisch]

Charles A. Crayne wrote:
> I have recently acquired a XITEL INPORT device, to capture music from my
> stereo system, and although [as shown below] it seems to be supported by
> the FC3 kernel, I have not yet managed to find any way to access the USB
> data stream.
>
> arecord -l
> card 1: Audio [USB Audio], device 0: USB Audio [USB Audio]

Record from device "hw:1" or "plughw:1".  See
/proc/asound/card1/stream0 for a list of supported sample formats.


HTH
Clemens

Re: [linux-audio-dev] Re: EMI26

[Clemens Ladisch]

Andrew Burgess wrote:
> Mine comes up as 102, I've had to edit the driver source in the
> past to get it to work. Could you make sure 102 will work too?

The firmware for IDs 0100 and 0102 is indeed the same.

Editing drivers/usb/misc/emi26.c in the kernel source and replacing
0x0100 with 0x0102, and then recompiling the kernel, should enable it
to work.


HTH
Clemens

Re: [linux-audio-dev] Developing and audio driver

[Clemens Ladisch]

fred doh wrote:
> The OSS doc seems to be directed to the user of the API and not
> for the driver developer.

These docs describe the interface between applications and the driver,
so you can read them "from the other side".


But I'd really recommend to write an ALSA driver instead.


Regards,
Clemens

Re: [linux-audio-dev] EMI26 (was: Welcome to the "linux-audio-dev" mailing list)

[Clemens Ladisch]

krsrtn wrote:
> after that I looked at what you said, /proc/bus/usb/devices::
> ...
> D:  Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
> P:  Vendor=086a ProdID=0102 Rev= 0.01
> C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> I:  If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> ...

The firmware wasn't loaded.

> ok. this is the output of lsusb after I modprobed emi26:
>
> Bus 004 Device 002: ID 086a:0102 Emagic Soft-und Hardware GmbH

The emi26 module expects the device to have product ID 0100.  It seems
you have a new hardware revision.

I'll see if I can update the emi26 driver.


Regards,
Clemens

Re: [linux-audio-dev] EMI26 (was: Welcome to the "linux-audio-dev" mailing list)

[Clemens Ladisch]

krsrtn wrote:
> 0 [ICH5   ]: ICH4 - Intel ICH5
>  Intel ICH5 with ALC202 at 0xcc00, irq 177
> 1 [VirMIDI]: VirMIDI - VirMIDI
>  Virtual MIDI Card 1
> 2 [Modem  ]: ICH-MODEM - Intel ICH5 Modem
>  Intel ICH5 Modem at 0x2400, irq 177
> 3 [Controller ]: USB-Audio - UC-33 USB MIDI Controller
>  Evolution Electronics Ltd. UC-33 USB MIDI Controller at 
> usb-:00:1d.1-1, ful
>
> so it doesn't even appear there so I thought to look at dmesg::
>
> usbcore: registered new driver emi26 - firmware loader
> usb 4-1: USB disconnect, address 2
> hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
> hub 3-0:1.0: over-current change on port 1
> usb 3-1: USB disconnect, address 2
> usb 3-1: new full speed USB device using uhci_hcd and address 3
> usb 4-1: new full speed USB device using uhci_hcd and address 3
> midi: probe of 4-1:1.0 failed with error -5
>
> these are the last messages at the bottom, after I re-connected the
> device. does it mean it recognised the device and it works or not?

It seems the firmware got loaded.

Does it appear in the output of lsusb?  What are the contents of
/proc/bus/usb/devices after the emi26 module has been loaded?

> my modprobe.conf looks like this::
>
> alias snd-card-0 snd-usb-audio
> options snd-card-0 index=0

You cannot have options on an alias.  Your options lines should look
like this:

options snd-usb-audio index=0,1
options snd-intel8x0 index=2
options snd-virmidi index=3
options snd-intel8x0m index=4

> what is 'top-post' by the way?

A: No.
Q: Should I include quotations after my reply?


Regards,
Clemens

Re: emi26 [was: Re: [linux-audio-dev] Re: Welcome to the "linux-audio-dev" mailing list9

[Clemens Ladisch]

(please don't top-post)

krsrtn wrote:
> ok, but still the frimware is not claimed by the device:
>
> [EMAIL PROTECTED] ~]$ lsmod | grep emi26
> emi26 168704  0

This driver just loads the firmware.  After that, the device is a
standard USB audio device, and the snd-usb-audio driver takes over.

> I don't understand what else there is to do to make it appear (in jack
> for example).

Is snd-usb-audio loaded?  Is audio not loaded?
Does it appear in /proc/asound/cards?


Regards,
Clemens

Re: [linux-audio-dev] Linux DSP Hardware?

[Clemens Ladisch]

Shane wrote:
> There has been some fuss in the past about linux drivers for some of the
> Creamware products.  It's been mentioned that drivers for linux are back
> under development but creamware has swayed on this issue before.  I
> couldn't say exactly what is going on in this area,

In March 2004, a mailing list for OSX/Linux developers was formed.
The last mail is from September 2004 and says that the paperwork
required for an NDA so that people can start talking about how to
design any driver hasn't yet been done.


Clemens

Re: [linux-audio-dev] Linux DSP Hardware?

[Clemens Ladisch]

jipi wrote:
> currently, all signal processing algos are being done in software for
> Linux Audio.
> are there any hardware accelerated support for audio hardware when doing
> these sort of algos?

If you bend the definition of "hardware accelerated" enough, SIMD
extensions like MMX/SSE... would qualify. :)

> what if we want to experiment with h/w dsp?

The DSP on emu10k1 cards is the only one supported in Linux.

> (e.g. the 1820m from creative professional aka emu)

I don't know how similar that DSP is to the one on Creative's game
("consumer") cards, but it probably is somewhat related.  But Creative
doesn't release documentation, so we can forget it.


Clemens

Re: [linux-audio-dev] M-Audio Transit USB with ALSA?

[Clemens Ladisch]

Albert Graef wrote:
> has anyone tried the M-Audio Transit USB with ALSA yet?

It should work, but you need the firmware loader from
.

> I'm looking for a not-too-expensive USB audio interface for my laptop,

http://www.qbik.ch/usb/devices/


HTH
Clemens

Re: [linux-audio-dev] [Alsa-devel] [PATCH]: better X-Station/Speedio/ReMOTE25 support

[Clemens Ladisch]

Charles C. Bennett, Jr. wrote:
> The patch should apply cleanly to any kernel tree with
> ALSA 1.7 and build just fine.

The driver had some little changes in version 1.0.8.  Additionally,
I've been adding yet another protocol (for MOTU devices), and this
resulted in too many quirky "if"s sprinkled all over the code, so I've
rewritten the handling of the MIDI protocol stuff with callbacks.

I had some code for the Novation protocol for several weeks, but
didn't find any testers who actually tested it -- so you're now my
victim.  ;-)


This patch is against the current ALSA CVS.  If you modifiy your
kernel, you need only the changes below alsa-kernel/.  If you don't
have the CVS version, you can get the patched files from
<http://www.informatik.uni-halle.de/~ladischc/usbmidi.tar.gz>.


Best regards,
Clemens

-- 
Index: alsa-driver/usb/usbmidi.c
===
RCS file: /cvsroot/alsa/alsa-driver/usb/usbmidi.c,v
retrieving revision 1.15
diff -u -r1.15 usbmidi.c
--- alsa-driver/usb/usbmidi.c   20 Jan 2005 17:25:30 -  1.15
+++ alsa-driver/usb/usbmidi.c   26 Jan 2005 15:56:47 -
@@ -13,7 +13,6 @@
 #ifdef OLD_USB
 #define snd_usb_complete_callback(x) __old_ ## x
 static void __old_snd_usbmidi_in_urb_complete(struct urb* urb);
-static void __old_snd_usbmidi_in_midiman_complete(struct urb* urb);
 static void __old_snd_usbmidi_out_urb_complete(struct urb* urb);
 #endif

@@ -25,11 +24,6 @@
snd_usbmidi_in_urb_complete(urb, NULL);
 }

-static void __old_snd_usbmidi_in_midiman_complete(struct urb* urb)
-{
-   snd_usbmidi_in_midiman_complete(urb, NULL);
-}
-
 static void __old_snd_usbmidi_out_urb_complete(struct urb* urb)
 {
snd_usbmidi_out_urb_complete(urb, NULL);
Index: alsa-kernel/usb/usbaudio.c
===
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.114
diff -u -r1.114 usbaudio.c
--- alsa-kernel/usb/usbaudio.c  17 Jan 2005 17:41:34 -  1.114
+++ alsa-kernel/usb/usbaudio.c  26 Jan 2005 15:56:47 -
@@ -2965,6 +2965,8 @@
case QUIRK_MIDI_FIXED_ENDPOINT:
case QUIRK_MIDI_YAMAHA:
case QUIRK_MIDI_MIDIMAN:
+   case QUIRK_MIDI_NOVATION:
+   case QUIRK_MIDI_MOTU:
return snd_usb_create_midi_interface(chip, iface, quirk);
case QUIRK_COMPOSITE:
return create_composite_quirk(chip, iface, quirk);
Index: alsa-kernel/usb/usbaudio.h
===
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.h,v
retrieving revision 1.36
diff -u -r1.36 usbaudio.h
--- alsa-kernel/usb/usbaudio.h  17 Jan 2005 17:41:38 -  1.36
+++ alsa-kernel/usb/usbaudio.h  26 Jan 2005 15:56:47 -
@@ -158,6 +158,8 @@
 #define QUIRK_AUDIO_EDIROL_UA700_UA25  7
 #define QUIRK_AUDIO_EDIROL_UA1000  8
 #define QUIRK_IGNORE_INTERFACE 9
+#define QUIRK_MIDI_NOVATION10
+#define QUIRK_MIDI_MOTU11

 typedef struct snd_usb_audio_quirk snd_usb_audio_quirk_t;
 typedef struct snd_usb_midi_endpoint_info snd_usb_midi_endpoint_info_t;
@@ -172,7 +174,10 @@

 /* data for QUIRK_MIDI_FIXED_ENDPOINT */
 struct snd_usb_midi_endpoint_info {
-   int8_t out_ep, in_ep;   /* ep number, 0 autodetect */
+   int8_t   out_ep;/* ep number, 0 autodetect */
+   uint8_t  out_interval;  /* interval for interrupt endpoints */
+   int8_t   in_ep;
+   uint8_t  in_interval;
uint16_t out_cables;/* bitmask */
uint16_t in_cables; /* bitmask */
 };
@@ -191,7 +196,9 @@

 /* for QUIRK_AUDIO_EDIROL_UA700_UA25/UA1000, data is NULL */

-/* for QUIRK_IGNORE_INTERFACE, data is null */
+/* for QUIRK_IGNORE_INTERFACE, data is NULL */
+
+/* for QUIRK_MIDI_NOVATION and _MOTU, data is NULL */

 /*
  */
Index: alsa-kernel/usb/usbmidi.c
===
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbmidi.c,v
retrieving revision 1.35
diff -u -r1.35 usbmidi.c
--- alsa-kernel/usb/usbmidi.c   29 Nov 2004 14:09:48 -  1.35
+++ alsa-kernel/usb/usbmidi.c   26 Jan 2005 15:56:47 -
@@ -1,7 +1,7 @@
 /*
  * usbmidi.c - ALSA USB MIDI driver
  *
- * Copyright (c) 2002-2004 Clemens Ladisch
+ * Copyright (c) 2002-2005 Clemens Ladisch
  * All rights reserved.
  *
  * Based on the OSS usb-midi driver by NAGANO Daisuke,
@@ -77,11 +77,18 @@
 typedef struct usbmidi_out_port usbmidi_out_port_t;
 typedef struct usbmidi_in_port usbmidi_in_port_t;

+struct usb_protocol_ops {
+   void (*input)(snd_usb_midi_in_endpoint_t*, uint8_t*, int);
+   void (*output)(snd_usb_midi_out_endpoint_t*);
+   void (*output_packet)(struct urb*, uint8_t, uint8_t, uint8_t, uint8_t);
+};
+
 struct snd_usb_midi {
snd_usb_audio_t *chip;
struct usb_interface *iface;
const snd_usb_audio_quirk_t *quirk;
snd_ra

Re: [linux-audio-dev] Trying to record midi with OSS

[Clemens Ladisch]

[EMAIL PROTECTED] wrote:
> However, I'm unable to get rosegarden21 to record any
> midi notes.

This may be the same as this bug:



HTH
Clemens

Re: [linux-audio-dev] muse and /dev/rtc

[Clemens Ladisch]

Alfons Adriaensen wrote:
> the ALSA sequencer API seems to allow *timestamped* events - you put such
> an event in a queue and it will appear at the other end at the right moment.
> If this is true,

It is.

> and if ALSA has an high precision timer available to implement it,

Standard 2.4 kernels don't have an high precision timer, unless the
sound card hardware implements one, or if the RTC patch is used.  On
2.6 kernels, the system timer is precise enough.

> why should apps like MusE bother to do the fine timing themselves
> ?

Probably backwards compatibility (with 2.4 kernels _and_ OSS).


Best regards,
Clemens

Re: [linux-audio-dev] cli midi

[Clemens Ladisch]

Hans Fugal wrote:
> Is there an app that will dump midi events in human-readable format to
> stdout (or a file, or gui window, whatever)?

"arecordmidi --dump"; or the tool I posted last week:


("amidi --dump" is human-readable, too, if you happen to have the
right human at hand.  ;-)


HTH
Clemens

Re: [linux-audio-dev] Novation ReMOTE, Speedio & XStation

[Clemens Ladisch]

Nick Dowell wrote:
> The MIDI communication is not class compliant. It is a very simple
> protocol though, and should be easy to implement. If anyone wants
> information to write one we'd be more than happy to give it.

I'm definitely interested in implementing this protocol.


Best regards,
Clemens

Re: [linux-audio-dev] USB sound card for Mac and PC

[Clemens Ladisch]

Frank Barknecht wrote:
> And thanks to Clement,

who?  ;-)

> Clemens Ladisch hat gesagt: // Clemens Ladisch wrote:
> > > There is the M-Audio Audiophile USB but it does not work on Gentoo (and
> > > of course, I use Gentoo!!).
> >
> > It should work with recent driver versions.
>
> I was off-list for a while: Does this mean, that the Alternate ID
> problem is finally solved somehow?

AFAIK the latest 2.6 kernel works around all the various M-Audio
'features'.

> And that I might be able to try using the Quattro again?

The latest Quattro-related change in the driver was in ALSA 1.0.6.


HTH
Clemens

Re: [linux-audio-dev] USB sound card for Mac and PC

[Clemens Ladisch]

Pamplemousse Mk2 wrote:
> > Whatever you buy, look for (how to say?), look for an indication that it
> > will work in MacOS(X) without any additional install of drivers ...
> > Which translates into that the device is "standards-compliant" and
> > *should* work out of the box with your Linux box (or for that matter,
> > any host aware of usb sound and/or midi)

Often it's called "optimized for Windows XP/OS X" or
"class-compliant".

> I am interesting about these cards:
> - M-Audio MobilePre USB

Installation is nontrivial due to the firmware loader.

> - Terratec Phase 26 USB (not tested on 2.6 kernel by Linux-USB, but
> should work fine).

Frank made the tests with both 2.4 and 2.6.

> There is the M-Audio Audiophile USB but it does not work on Gentoo (and
> of course, I use Gentoo!!).

It should work with recent driver versions.

> With one of these cards, I would be able to plug my mixer (Technics
> SH-DJ 1200) on it and make phrase and live sample.

With a mixer, you probably don't need things like a preamp or hi-Z
inputs.  Something very simple like the Edirol UA-1X might suffice.

> 1 - Is it right to consider ALSA as an ASIO-like driver for Linux?

Yes.  (Nowadays, all operating systems have built-in ASIO-like
features.)

> 2 - Is there a noticeable difference between 16bit/44kHz and 24/96KHz?
> Especially when recording from sources like records or CD?

Probably not, but it wouldn't hurt.  :-)
(And the perfect way to record CDs is to rip them digitally.)


HTH
Clemens

Re: [linux-audio-dev] USB sound card for Mac and PC

[Clemens Ladisch]

Pamplemousse Mk2 wrote:
> Is there any USB sound card compatible with both Mac and PC under Linux?

The sound drivers run on all architectures.  You can use any supported
device.

> My sound card would be used essentially for full duplex recording, and
> sampling in live with software that I code or buy. Could someone give me
> name of good USB soundcard?

Edirol devices are good (but not cheap).
Have a look at .


HTH
Clemens

Re: [linux-audio-dev] M-Audio Sonica/Ozone/MobilePre/Transit firmware loader now works

[Clemens Ladisch]

Stephen Hassard wrote:
> I just tried madfu with my Sonica, and I get a segfault.
>
> madfuload  -f ma005101.bin --waitbyte3 -D /proc/bus/usb/002/003
> Segmentation fault

Please show the output when you add the -v parameter.


Clemens

[linux-audio-dev] M-Audio Sonica/Ozone/MobilePre/Transit firmware loader now works

[Clemens Ladisch]

Hi,

it has been reported that the 2.6.8 kernel has fixed the handling of
USB resets, so now it's possible to use a Linux firmware loader to get
these devices to work.

You can get the loader at .


Best regards,
Clemens

Re: [linux-audio-dev] a question re: the MIDI spec

[Clemens Ladisch]

Martijn Sipkema wrote:
> > > It's not unusable, but IIRC it can get to several ms of jitter.
> >
> > Why is that? The USB iso clock is every ms IIRC, so naively you
> > would expect the maximum jitter to be just under 1ms (if the bus was
> > saturated by audio transfers), and less in proportion to the degree of
> > saturation.

USB transfers always wait for the beginning of the next frame, so the
maximum jitter is never less than 1 ms, even on an otherwise free bus.

> Yes, one would expect that (if there are no other bulk transfers), but
> somehow this does not seem to be the case:
>
> http://www-2.cs.cmu.edu/~eli/papers/icmc01-midiwave.pdf

These measurements include the jitter added by the drivers and by the
high-quality realtime-capable (yeah :-) Windows 98 scheduler.

I did some similar measurements under Linux, and it seems the jitter
isn't bigger than the expected 1 or 2 ms (2 because MIDI through
involves two USB transfers).


Regards,
Clemens

Re: [linux-audio-dev] a question re: the MIDI spec

[Clemens Ladisch]

Jens M Andreasen wrote:
> [...] the USB specification. And it even appears like some vendors
> are (finally!) starting to follow suit:
>
>http://midiman.com/products/en_us/KeystationPro88-main.html
>
>- "USB class compliant—no drivers required for
>  Windows XP or Mac OS X"

M-Audio started following suit only after they hung their engineers
with a USB cable and bought Evolution who had always made
class-compliant devices.


Regards,
Clemens

Re: [linux-audio-dev] a question re: the MIDI spec

[Clemens Ladisch]

Dave Phillips wrote:
>   I'm doing some research for an article about Linux MIDI support. In my
> text I briefly describe the evolution of the MIDI specification since
> its adoption, mentioning things like MIDI Time Code, MMC, the sample
> dump standard, and the standard MIDI file. However, one item has me a
> bit mystified. I'm unable to ascertain whether multi-port interfaces are
> in fact described and supported by the spec.

SMF files can have the "MIDI Port" meta event (FF 21) to specify the
port number for the following events.  RP-019 describes the "device
name" meta event (FF 09) with exactly the same purpose
(), but it isn't used
in practice.


HTH
Clemens

Re: [linux-audio-dev] Firewire Breakout-Boxes

[Clemens Ladisch]

Daniel Wagner wrote:
> > You really should get in contact with the ALSA guys.
>
> I have already posted a message there couple of weeks ago.

Messages from non-subscribers are routed to /dev/null because there
isn't a moderator.


Clemens

Re: [linux-audio-dev] Re: [linux-audio-user] Setting up linux computer

[Clemens Ladisch]

Paul Winkler wrote:
> On Tue, Aug 24, 2004 at 04:23:10PM +0200, Clemens Ladisch wrote:
> > The snd-usb-audio driver currently supports multiport USB
> > interfaces from ESI/Edirol/Roland/M-Audio/Yamaha.
>
> Note that others have reported issues with the M-audio usb devices.

The MidiSport MIDI interfaces work just fine (once you have managed to
get the firmware and to install the firmware loader).  It's the audio
interfaces that have (rather major) "issues".


Regards,
Clemens

[linux-audio-dev] Re: [linux-audio-user] Setting up linux computer

[Clemens Ladisch]

ChristianH wrote:
> - and I assume MIDI interface as well (6 to 8 ports in+out)
>
> For Windows I was considering an Emagic AMT8 or Unitor8 interface,

There is no Linux driver for these.  The snd-usb-audio driver
currently supports multiport USB interfaces from ESI/Edirol/
Roland/M-Audio/Yamaha.


HTH
Clemens

Re: [linux-audio-dev] swh plugins and fixing undenormalize

[Clemens Ladisch]

Steve Harris wrote:
> You can do
>
> y += delta
> y -= delta
>
> but youre at the mercy of the optimiser.

The IEEE standard specifies exactly what happens with denormals, so,
in theory, the compiler must not optimize this away.  However,
optimization options for speed often disable strict IEEE
compatibility.  (I don't know how gcc's options behave.)

> A C99 safe version of the obove macro (with a bit of extension, to catch
> "P4 denormals") is:
>
> typedef union {
> float f;
> int32_t i;
> } ls_pcast32;
> ...
> v.f = f;
> return (v.i & 0x7f80) < 0x0800 ? 0.0f : f;

AFAIK this isn't safe either because the same type aliasing rules
apply to unions, too.  The only safe way is to go through char
pointers.


Regards,
Clemens

Re: [Alsa-devel] [linux-audio-dev] DSP2000 C-PORT and MIDI input

[Clemens Ladisch]

Lukas Degener wrote:
> Hi everybody and sorry for posting this to both, lad and alsa-dev,
> i was not sure which one fits better.

alsa-devel would be appropriate, but non-subscribers cannot post
there, so I'm keeping linux-audio-dev in the CCs.

> Concerning the issue with non-functional midi in on the DSP2000 c-port:
> Someone on lau(Clemens?) said the problem is a lack of information an
> how to enable some interrupts.

>From what I've heard, interrupts just don't happen.  The MIDI receiver
is part of the ICE1712 chip, so, apparently, the MIDI input isn't
enabled or in power saving mode or something like that.

MIDI input works with this driver on ICE1712-based cards from other
vendors, so this seems to be some Hoontech-specific configuration
issue.

> > Matthew Skinner, Sound and Music Tech Support wrote:
> >
> > > If you can program in c++ and want to get the midi io working
> > > on the cport then let me know what you need.

I need to know how exactly the box configuration registers(?) are to
be initialized for DSP* cards.  The driver currently fiddles with
three bits named MIDIIN, MIDI1, and MIDI2, but their function seems to
be more complex than the names imply.

And the driver doesn't actually know about the C-Port.  There are two
known EEPROM subdevice IDs: 0x1712/0x1412 for the DSP24, and
0x1712/0x1416 for the Media7.1.  I guess the C-Port uses one of these
IDs?  (Otherwise, this would explain why the C-Port isn't initialized
completely.)


Regards,
Clemens

Re: [linux-audio-dev] [request] Info on the Awe32 schematics

[Clemens Ladisch]

Juan Linietsky wrote:
> Does any of you know how to get PROPER docummentation on the Sound Blaster
> AWE32? and If possible, official datasheets or something..

It is sometimes said that not even Creative's driver developers get
proper datasheets ...

> I think creative's official devkit is gone from the internet...

The manual on the ALSA FTP server is only up to SB16.

> Do you guys also know if people from the opensource creative site
> would be kind enough to send me that?

We won't know until you've tried.  ;-)


Regards,
Clemens

Re: [linux-audio-dev] Vsound-like tools for ALSA?

[Clemens Ladisch]

Mark Constable wrote:
> On Wed, 28 Jan 2004 07:42 pm, Mike Rawes wrote:
> > pcm.fileout {
> >   type file
> >   slave.pcm "hw:0,0"
> >   file alsaout.raw
> > }
> >
> > ..then aplay -D fileout foo.wav, will create a file called alsaout.raw
>
> ... and, how would one go about doing this for pmidi, an
> ALSA app that does not support the -D option ?

pmidi plays MIDI events, not PCM data.  You have to record the output
of the synthesizer to get PCM data.

> And is it safe to presume this file will get created in
> the current directory ?

Yes.  The definition is read by the ALSA library, which is part of the
process of whatever program that is using the ALSA device.

> > Quite how you determine the format of the .raw file is beyond me -
> > anybody?!

.raw files don't have any header, so you have to guess.  (The sample
format is almost always S16_LE, but for the number of channels (mostly
1 or 2) or the sample rate, you have to try until it doesn't sound too
bad.  ;-)


HTH
Clemens

Re: [linux-audio-dev] Re: [Alsa-devel] alsa 1.0.0 API changes???

[Clemens Ladisch]

Maarten de Boer wrote:
> Out of curiosity: how did you manage to keep binary compatibility?

With assembler magic (see alsa-symbols.h and pcm.h).


Regards,
Clemens

Re: [linux-audio-dev] Linux Security Module for realtime audio

[Clemens Ladisch]

Jesper Anderson wrote:
> On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote:
> > Do they have a valid reason?  Or are they just imposing their paranoia on us
> > for fun?
>
> Their explanation is here:
>
> http://www.gtk.org/setuid.html

Good reasons, IMHO.

And I see no reason why drawing a colorful GUI should require realtime
privileges -- it's the other way round: the audio processing should
have priority over the GUI.

Seperating the audio engine and the GUI into different processes is
the unixy way anyway.


Regards,
Clemens

Re: [linux-audio-dev] M-audio transit/ozone/MobilePre experiences?

[Clemens Ladisch]

[EMAIL PROTECTED] wrote:
> Does the M-audio MobilePre work with Linux?

No.

> Earlier there was a 'beta' released (by Clemens Ladisch):

It doesn't work. I think there is a bug in the USB subsystem in the
kernel, but I don't have time to research further now.

Currently, these devices don't work with Linux at all.

> I am also considering the Tascam US-122 as an alternate,

This one isn't fully compatible with the USB Audio specification,
either.  I'm not sure if the special driver supports all features.


HTH
Clemens

Re: [linux-audio-dev] MIDI part II

[Clemens Ladisch]

[EMAIL PROTECTED] wrote:
> alsa-0.9.7 ( current version) seems to need some "magic" to get
> started

What exactly is your problem with 0.9.7?


Regards,
Clemens

[linux-audio-dev] M-Audio MobilePre/Sonica/Transit/Ozone testers wanted

[Clemens Ladisch]

The M-Audio MobilePre/Sonica/Transit/Ozone devices need a firmware
download before they can be used with Linux.

I've released a first beta of the madfu-firmware package which tries
to accomplish this.

Please note that I do not have any of these devices, and that the
loader is not tested at all. That's why I'm searching for volunteers.
:-)

To download the beta, go to
http://sourceforge.net/project/showfiles.php?group_id=8&release_id=183375

Please send any success/failure reports to
[EMAIL PROTECTED]


Regards,
Clemens

[linux-audio-dev] [ANN] MidiSport firmware loader 0.2

[Clemens Ladisch]

The MidiSport firmware loader allows to use the MidiSport USB MIDI
interfaces from M-Audio/Midiman with Linux.

Version 0.2 fixes a bug in the loader script which tried to load the
firmware files from the wrong directory.

Supported devices:
MidiSport 1x1, 2x2, 4x4, 8x8, KeyStation, Oxygen, Radium, Uno.

To download the loader, go to the project home page:
http://usb-midi-fw.sf.net/


-- 
Clemens

Re: [linux-audio-dev] MIDI files contain strange byte sequences ?

[Clemens Ladisch]

Benno Senoner wrote:
> I'm just writing some MIDI file  ( SMF 0/1) loading routines and
> while the file structure is quite simple I came across some MIDI files
> (mainly .KAR (=midi + embedded lyric events)) where there are some
> byte sequences that do not make sense to me.
> (attaching a short hexdump at the end of mail).
>
> Basically I read the  MTrk shown below and after the
> ff 01 TEXT meta event which contains the text 'Reset Volume'
> there are sequences of 00 07 7f till the next ff 01 text event
> 'Reset Pan'.

...
8142 b1 0a 40
00 5b 40
00 07 00
85f810 ff 01 0c 52 65 73 65 74 20 56 6f 6c 75 6d 65 "Reset Volume"
00 07 7f
00 07 7f
00 07 7f
...

Apparently, the software that wrote this file thought it could use
running status, but as Pedro said, FF meta-events cancel running
status. This file clearly violates the SMF specification.

And there are exactly 16 "00 07 7f" commands, so I think the intention
was to reset all 16 channels (which isn't possible at all with running
status).

(There is a status byte for the pitch bends, but this one is
repeated with running status 15 times, too.)


HTH
Clemens

Re: [linux-audio-dev] simultanious access to audio input

[Clemens Ladisch]

Robert Ross wrote:
> I need to allow multiple programs/processes to take data from the same
> audio device at the same time.

ALSA has the dsnoop plugin for this. This isn't very well documented,
but you might be able to find some example in the ALSA list archives.


HTH
Clemens

Re: [linux-audio-dev] System Exclusive question

[Clemens Ladisch]

[EMAIL PROTECTED] wrote:
> Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> > My unit's light is active while the dump is being transmitted (several
> > seconds, depending on the size of the data). Are you sure your's is
> > sending anything?
>
> The MIDI activity light flashes *very* briefly, so it could be that
> nothing's being sent back.

My knowledge is limited to GS sysexs only, but I think your address
04 01 76 / length 00 01 76 may not be correct. The lower two bytes are
identical. Does the parameter at address 04 01 76 really have a length
of F6h bytes?

> > [EMAIL PROTECTED] wrote:
> > > I have tried using Linux, but gave up when I couldn't get ALSA or
> > > OSS to recognise my USB MIDI interface, (a Yamaha UX96). Under
> > > NetBSD it's recognised as soon as I plug it in.
> >
> > Any somewhat recent version of ALSA does support the UX96.
>
> I tried RedHat 9.0 and the CCRMA stuff, but I guess I mustn't have setup
> the modules.conf file properly.

The snd-usb-audio driver doesn't really need any entries in
modules.conf, except when you want to force it to have a specific card
number.

The module should be automatically loaded by the hotplug scripts when
you plug in the USB device (or when booting).

> I assume I need an entry in there to load the USB MIDI interface
> driver - could you send me your modules.conf so I can see what
> sort of entries are required?

Something like the following: (I'm assuming you have another sound
card as the first card)

# ALSA stuff
alias char-major-116 snd
options snd cards_limit=2

alias snd-card-0 snd-whatever
options snd-whatever index=0 some_option=42

alias snd-card-1 snd-usb-audio
options snd-usb-audio index=1

# OSS emulation stuff
alias char-major-14 soundcore
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-8 snd-seq-oss

alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-12 snd-pcm-oss

alias sound-slot-1 snd-card-1
alias sound-service-1-0 snd-mixer-oss
alias sound-service-1-3 snd-pcm-oss
alias sound-service-1-12 snd-pcm-oss


HTH
Clemens

Re: [linux-audio-dev] System Exclusive question

[Clemens Ladisch]

[EMAIL PROTECTED] wrote:
> Jay Vaughan <[EMAIL PROTECTED]> wrote:
> > >Has anyone had succes in getting SysEx data flowing back and forth
> > >between Roland sound modules and their computer?

Yes, SC-8820, over USB.

> > >I have attached my
> > >simple test program in case I'm doing something obviously wrong.

I see nothing obviously wrong.

It might be time-saving to try the low-tech approach first:
do a "cat /dev/midi42 > somefile", then, on another console, run:

echo -ne '\xf0\x41\x10\x16\x11\x04\x01\x76\x00\x01\x76\x0e\xf7' > /dev/midi42

> > > However, whenever I send a Request Data
> > >message the unit doesn't appear to respond. It definitely receives the
> > >message as the MIDI activity light comes on. But when I try to read from
> > >the MIDI device file my call blocks forever.

My unit's light is active while the dump is being transmitted (several
seconds, depending on the size of the data). Are you sure your's is
sending anything?

> I have tried using Linux, but gave up when I couldn't get ALSA or
> OSS to recognise my USB MIDI interface, (a Yamaha UX96). Under
> NetBSD it's recognised as soon as I plug it in.

Any somewhat recent version of ALSA does support the UX96.


HTH
Clemens

Re: [linux-audio-dev] midi 'resolution'

[Clemens Ladisch]

Lukas Degener wrote:
> In a system/application, that recieves external midi data of any kind,
> is there anything one can assume about _when_ some midi data is recieved?

The data is received when the hardware raises an interrupt to notify the
driver that some data is available, which can be at any time. (see
Martijn's answer)

> i mean, with audio data, you have the buffer size of the dac/adc, which
> (together with sampling rate) enforces some kind of "global clock"
> impulse/trigger in your system.
>
> Is there anything similar with midi data?

Usually no.

With USB (1.x), however, interrupts are generated at the end of each 1ms
frame only.


HTH
Clemens

Re: [linux-audio-dev] request for a small app

[Clemens Ladisch]

Dave Phillips wrote:
> I'm wondering if it might be possible to whip up a small app that
> displays the following:
>
>   ALSA/JACK connection status
>   patch name update
>   MIDI message flow (minus active sensing, of course)

ASeqView does something like that.



HTH
Clemens

[linux-audio-dev] Re: [linux-audio-user] problems with Midisport 2x2

[Clemens Ladisch]

Ivica Bukvic wrote:
> I've got a small problem with my Midisport 2x2 MIDI interface. While it worked
> ok before, now for some odd reason I cannot get it to open for MIDI output
> (from the computer). I've checked the /var/log/messages and this is what I
> got:
> [...]
> It says that the device was opened with 4 input and 0 output ports. Why is
> this the case?

It's a bug in ALSA 0.9.0rc7. You could get the current CVS version, or
apply the following patch:

Index: usbmidi.c
===
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbmidi.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- usbmidi.c   13 Jan 2003 09:50:26 -  1.18
+++ usbmidi.c   3 Feb 2003 09:58:14 -   1.19
@@ -821,7 +821,7 @@
ms_ep->bDescriptorType != USB_DT_CS_ENDPOINT ||
ms_ep->bDescriptorSubtype != MS_GENERAL)
continue;
-   if ((ep->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) == USB_DIR_OUT) {
+   if ((ep->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_OUT) {
if (endpoints[epidx].out_ep) {
if (++epidx >= MIDI_MAX_ENDPOINTS) {
printk(KERN_WARNING "snd-usb-midi: too many 
endpoints\n");


HTH
Clemens