Kevin Cole wrote:
> In my limited readings, I had gotten the vague impression that OSC was sort
> of MIDI 2.0.
OSC is similar to MIDI, and some parts could be translated from/to MIDI, but
it is not compatible with MIDI.
Regards,
Clemens
___
Jonathan E. Brickman wrote:
> it says it's TCP, not UDP, and it is using a connected socket which
> means TCP I do believe.
Sockets work with both TCP and UDP.
> I had thought RTP-MIDI was UDP?
RTP is specified for both TCP and UDP.
> I wonder if judicious use of UDP would improve performance
Jacek Konieczny wrote:
> On 2018-06-14 22:14, Clemens Ladisch wrote:
>> Christopher Arndt wrote:
>>> I'd like to monitor, what MIDI data the application is sending to the
>>> device.
>>
>> Does Wine use sequencer ports? Then you could configure the snd-
Christopher Arndt wrote:
> I have a proprietary Windows application (tc electronic TonePrint
> editor) running under Wine, which talks to a class-compliant* USB MIDI
> device (Flashback delay pedal).
>
> I'd like to monitor, what MIDI data the application is sending to the
> device.
Does Wine use
Jonathan E. Brickman wrote:
> I need to connect ALSA MIDI programmatically, and will prefer to use
> Python.
Just run aconnect. :-)
> I perused a number of libraries, did not find an obvious great
> or best.
Making a connection should be a single function calls, it's either
"works" or "does not
Nikita Zlobin wrote:
> While configuring kernel, i stucked on option CONFIG_RAW_DRIVER, which
> enables /dev/raw device section.
>
> I suppose, things like linuxsampler or others, hardly working with
> storage, might utilize this access way for most direct access to
> samples. Or even in audio
Felipe Ferreri Tonello wrote:
> This event we are discussing is time based.
> The only difference is that the event time is not its delivered time,
> but some time in the past.
>
> I just want to make ALSA Sequencer support this idea, which is new and a
> requirement for MIDI over BLE to work
Felipe Ferreri Tonello wrote:
> On 20/09/16 15:26, Clemens Ladisch wrote:
>> In other words: any application that does care about timestamps will
>> never see your timestamps.
>
> Yes. And that's why my first question.
>
> How can we implement this timestamp featu
Felipe Ferreri Tonello wrote:
> On 19/09/16 13:27, Clemens Ladisch wrote:
>> And applications that care about the time of received events
>> tell the sequencer to overwrite the timestamp with the actual delivery
>> time anyway.
>
> Applications only need to car
Felipe Ferreri Tonello wrote:
> * We want to deliver these events *ASAP* to the application -
> scheduling adds latency, a lot;
> * Timestamps are in the past relative to the central.
>
> But I still need the timestamp information. Why? The spec doesn't
> explain, but it makes sense to believe
Felipe Ferreri Tonello wrote:
> On 16/09/16 18:41, Clemens Ladisch wrote:
>> Felipe Ferreri Tonello wrote:
>>> I have a question. I would like to send sequencer events without
>>> scheduling but with a timestamp information associated with. Is that
>>> possibl
Felipe Ferreri Tonello wrote:
> I have a question. I would like to send sequencer events without
> scheduling but with a timestamp information associated with. Is that
> possible?
You could set the timestamp field of the event, but why bother when
nobody is ever going to read it?
Regards,
OnkelDead wrote:
> I was able to patch my snd-usb-audio kernel driver to support all
> mixer interfaces of that device.
Please don't keep that information a secret.
Regards,
Clemens
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
Richard Cooper wrote:
> Is it possible to ask ALSA to also deliver these events early along with that
> timestamp?
No. You'd have to subtract the offset from the timestamp yourself.
Regards,
Clemens
___
Linux-audio-dev mailing list
Srinivasan S wrote:
Am facing overrun underrun issues, when I run the the above GSM application
with the attached asound.conf
The sound card and the GSM streams are not synchronized.
You need to compensate for the drift between the clocks, typically by
resampling.
(Jack's alsa_in/alsa_out
Srinivasan S wrote:
2. Could you please let me know, I have downloaded jack-1.9.10.tar.bz2, how
this needs to be installed in my rootfs
IIRC Jack uses some non-standard build system. Try asking on the Jack
mailing list how to cross-compile it.
Please note that the ALSA Jack plugin is part of
Will Godfrey wrote:
If you are using only small values is there really any benefit in using chars
and shorts rather than just using integers everywhere and letting the compiler
sort it out?
That depends on the CPU architecture.
Which is why stdint.h defines types like int16_fast_t.
Also,
Srinivasan S wrote:
could you please provide me some sample application links without
using dshare plugin , ie., using the two channels ie., left right
directly
I am not aware of any (sample) program that does something like this
(except maybe Jack, but floating-point samples would not be
Srinivasan S wrote:
CPU consumption is 18%, with above asound.conf the app
alsa_loopback_min_mono.c for establishing my GSM two way call (ie.,
VINR to VOUTR VINL to VOUTL) , this is very huge I want to reduce
this CPU consumption drastically, Is there any other ways in alsa where
I can do
Srinivasan S wrote:
I didn't understand what is 'two channel devices' does
The two channels are left and right.
Regarding bindings as you explainedbindings.x y or bindings { x y } maps
channel x of this device to
channel y of the slave device.
I didn't understand channel x of this device
Srinivasan S wrote:
$ aplay -f dat -D VOUTL new.wav
Playing WAVE 'new.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
aplay: set_params:1087: Channels count non available
You are trying to play a two-channel file on a single-channel device.
Regards,
Clemens
Srinivasan S wrote:
Could you please provide any inputs w.r.t the loopback card using
snd-aloop alsaloop, how this loopback card can be used to connect
the GSM two way call simultanoeusly to the UDA1345TS codec on MCASP0
of the am335x (UDA1345TS ie., real sound card)
snd-aloop creates a
hermann meyer wrote:
I try to fetch the bpm from the Midi Clock, and stumble over jitter.
How do you usually fetch the bpm from Midi Clock, any pointer will be welcome.
http://en.wikipedia.org/wiki/Phase-locked_loop
http://en.wikipedia.org/wiki/Kalman_filter
MIDI clock is interesting, because
Rafael Guayer wrote:
The plataform driver and the I2S hardware on the ARM SoC supports sample
resolutions of 16, 20 and 24 bits, and word sizes of 16, 20, 24 and 32
bits. Signed, little or big endian.
The i2s-DMA plataform driver and hardware, only 8, 16 and 32 bits transfers
are possible.
William Light wrote:
At the moment, when the audio thread (the JACK callback) needs to send a
message over a channel to another thread, it follows the common codepath
of appending the message to the channel's ring-buffer and then
write()ing to the eventfd. I suspect this is not real-time safe,
William Light wrote:
I shied away from pipes initially because I figured that staying in
user-space would let me keep tighter control on how quickly things
execute.
User-space code can be swapped out (unless you have mlocked it). So
_replacing_ user-space code with some kernel code that
Len Ovens wrote:
On Thu, 21 Aug 2014, John Rigg wrote:
... faders with a roughly logarithmic taper (no VCAs).
Which log? I would think .5 db for the same amount of movement the
entire fader length would be logarithmic (log 10).
For a fader from -INF to zero, alsamixer uses dB = 6000 *
Fons Adriaensen wrote:
In this case my very humble endeavour was just
to find out if or not it would be possible to
create something similar to the alsa_jack plugin
that would actually present itself as a sound
card, so that (badly written) apps would be
prepared to use it.
In theory,
Fons Adriaensen wrote:
if a device supports the pcm_resume() function, and it returns 0,
is a pcm_start() required or not?
If a device supports pcm_resume(), then the buffer is in the same
state it was when it was suspended, i.e., it is still running, and
continuing from the same position in
Fons Adriaensen wrote:
are there any devices that do support pcm_resume() ?
Search for SNDRV_PCM_INFO_RESUME in the kernel source.
(I fear lots of those drivers are lying.)
* is suspend/resume supposed to work with USB souncards ?
In theory, yes.
Regards,
Clemens
Jörn Nettingsmeier wrote:
I'm trying to get my Gigaport HD+ to run at 48000kHz. The specs say it is
capable of 8ch @ 44k1/16, 6ch at 44k1/24 and 48k/24.
Please show the output of lsusb -v for this device.
When I try to start it at 48k, it comes up ok but ends up running at 44k1. It
shows 8
Fons Adriaensen wrote:
On Tue, Feb 25, 2014 at 08:39:14AM -0500, Paul Davis wrote:
imagine you have an N (where N 16) channel device but only channels 1-4
are connected. the channel count option stops you from having to look at
N-4 useless channels on the device all the time.
AFAIK, when
Lucas Takejame wrote:
my task now is to make the kernel's usb audio driver more appropriate
to our sound card.
What specific problem do you have?
I was hoping that you could give me some directions on how can I
optimize the driver latency wise, any tips?
For playback, you get lower latency
Fons Adriaensen wrote:
If the problem is the same as with the original LP, then
the ALSA driver can't do anything about it, unless it would
contain LP-specific code.
The Launchpad S is class compliant and thus cannot use
running status.
Regards,
Clemens
Fons Adriaensen wrote:
On Tue, Oct 01, 2013 at 11:01:52AM +0200, Clemens Ladisch wrote:
Fons Adriaensen wrote:
If the problem is the same as with the original LP, then
the ALSA driver can't do anything about it, unless it would
contain LP-specific code.
The Launchpad S is class compliant
t...@trellis.ch wrote:
i'm trying to use a Roland R-26 as audio interface (USB).
I saw it is now officially supported in the alsa-driver repo log
This support is not complete.
Please show the output of lsusb -v for this device.
$ aplay a.wav
Playing WAVE 'rabe_babe.wav' : Signed 16 bit
t...@trellis.ch wrote:
- the Couldn't open device looks suspicious
I guess you are not root.
bmAttributes 37
Transfer TypeIsochronous
Synch Type Asynchronous
Usage Type Implicit feedback Data
I guess
Gordon JC Pearce wrote:
I'm having some really odd behaviour trying to send sysex to a synth
where I can only send (using snd_rawmidi_write) in three-byte blocks.
The USB MIDI protocol happens to send SysEx data in groups of three
bytes, but this does not need to concern you because any
Gordon JC Pearce wrote:
On Sat, Aug 31, 2013 at 11:34:33AM +0200, Clemens Ladisch wrote:
Gordon JC Pearce wrote:
The only exception is if I send something not a multiple of three
bytes but terminate the transfer with 0xf7, it will send
everything including the 0xf7 - but this kills the sysex
Gordon JC Pearce wrote:
On Sat, Aug 31, 2013 at 07:04:31PM +0200, Clemens Ladisch wrote:
not to send that too soon otherwise the CZ will misbehave in various
interesting ways. Once all the patch data is send - with breaks for
acks in between - the final 0xf7 is sent to terminate the sysex
Muffinman wrote:
snd_pcm_hw_params_any(alsa_handle, alsa_params);
snd_pcm_hw_params_set_access(alsa_handle, alsa_params,
SND_PCM_ACCESS_RW_INTERLEAVED);
snd_pcm_hw_params_set_format(alsa_handle, alsa_params,
SND_PCM_FORMAT_S16);
snd_pcm_hw_params_set_channels(alsa_handle,
culli...@rocketmail.com wrote:
Are there any limitations envolved with the quirks you do here?
There's only one way to find out ...
What is .ifnum 4 doing, which is now QUIRK_IGNORE_INTERFACE?
If I knew that, I wouldn't tell the driver to ignore it.
Regards,
Clemens
Paul Davis wrote:
(1) this is why it always pays to talk to clemens ladisch
Pay? Who? Whom? ;-)
(2) does this make yamaha liars for their claims of vendor dependent types?
Sometimes it's necessary to prevent the Windows driver from trying to
handle a device.
Regards,
Clemens
culli...@rocketmail.com wrote:
iManufacturer 1 Yamaha Corporation
iProduct2 Steinberg UR22
Interface Descriptor:
bInterfaceNumber1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol
Muffinman wrote:
I'm trying to poll mixer events in Alsa using C. I've used the following
functions within an infinite while loop:
...
snd_hctl_poll_descriptors(hctl, poll_fds, 1);
You are supposed to call snd_hctl_poll_descriptors_count() to get the
number of descriptors.
if
Muffinman wrote:
I'm struggling a bit with getting libao to work in C on Debian (Squeeze,
kernel 2.6.38.5, driver is Alsa). I've got this slightly modified test
script and it seems to work fine on my internal soundcard (it opens the
device and plays a test tone). However, when trying to do the
Alexandre Prokoudine wrote:
Is anybody interested to help Eigenlabs figure out the USB layer to
get their stuff ported to Linux?
http://www.eigenlabs.com/forum/threads/id/1148/
Does their stuff mean an audio driver for their USB thingy?
They imply that something ran on some old USB layer.
Thijs van severen wrote:
if there is no such page, wouldnt it be a good idea to create something like
this ?
The problem is not creating such a page (multiple ones already exist),
but keeping it up to date.
Regards,
Clemens
___
Linux-audio-dev
Paul Giblock wrote:
If your data structures and their use require locking, which you would like
to avoid, there is a concept called Read-Copy-Update which is for example
heavily used in the kernel and is also available as an userspace library
(http://lttng.org/urcu).
Yes, the RCU approach is
Jonathan Woithe wrote:
Though the UCX is not supported by FFADO, it is supported by ALSA if the
device is set to USB 2.0 class compliant mode.
That's neat. Has someone tested and verified this (on the RME site it
simply says that Linux should theoretically work)?
Well, the difference
gene heskett wrote:
# aplaymidi -l
PortClient name Port name
14:0Midi Through Midi Through Port-0
16:0SB Audigy 2 Value [SB0400] Audigy MPU-401 (UART)
16:32 SB Audigy 2 Value [SB0400] Audigy MPU-401 #2
17:0Emu10k1
gene heskett wrote:
And, is there a utility available that I can use to test send a file
to one of those midiC0Dn devices?
Raw MIDI devices require raw data; they're useful only for .syx files
where you don't care about timing.
Try this:
(echo -ne '\x90\x3c\x7f'; sleep 0.5; echo -ne
gene heskett wrote:
On Wednesday, December 14, 2011 02:03:14 PM Clemens Ladisch did opine:
... load the snd-virmidi module.
Tis loaded already:
$ lsmod|grep snd_seq_virmidi
No, the snd-virmidi module is not loaded.
[...]
aconnect -i
client 0: 'System' [type=kernel]
0 'Timer
harryhaa...@gmail.com wrote:
On , thijs van severen thijsvanseve...@gmail.com wrote:
any ideas ?
Yup! Tell jack to not use ALSA raw midi, use SEQ instead.
Raw MIDI ports do not allow sharing, so you have to tell all programs
you want to use at the same time to use the ALSA sequencer.
Instead
thijs van severen wrote:
amidi -l should list all midi out ports that are available to amidi, right?
It lists all ports implemented by an ALSA kernel driver. It is possible
to implement raw MIDI ports in software, but those are not listed.
Nick Copeland wrote:
I got curious, so I bashed out a quick program to benchmark pipes vs
POSIX message queues. It just pumps a bunch of messages through the
pipe/queue in a tight loop.
This benchmark measures data transfer bandwidth. If increasing that
were your goal, you should use some
I wrote:
What is the time quantum that sched_rr_get_interval() returns for these
threads?
Bah, the documentation of sched_rr_get_interval() is wrong; the kernel
uses a fixed RR time quantum of 100 ms which cannot be changed (except
by changing DEF_TIMESLICE in kernel/sched.c).
This means that,
Michael Ost wrote:
Have you ever seen migration or watchdog hold the CPU for any length of
time?
This shouldn't happen.
I was curious about migration since
/proc/sys/kernel/sched_migration_cost = 50
When migrating threads to another CPU (core), there is no big delay
because real-time
Michael Ost wrote:
The higher priority threads in the system are:
...
* IRQ8 (rtc) - FIFO/99
Why does this interrupt get such a high priority?
(Not that it matters as I don't expect it to be used at all ...)
Are there issues with memory mapping, that can block other unrelated
threads?
Then
Kazutomo Yoshii wrote:
Both the recording device and MIDI are working now.
$ arecord -f S32_LE -r 44100 -D hw:1,0 -c 2 a.wav
I got only S32_LE although AD or DA conversion is 24-bit.
Probably this is ok.
Most devices use 32-bit sample alignment because this makes the handling
easier for
Kazutomo Yoshii wrote:
I added an entry to quirks-table.h for BR-80 (see below) and recompiled
the snd-usb-audio module and re-installed the module.
The capture interface and MIDI seems not working.
As far as I can tell from the descriptors, interface 0 is a control
interface, _IGNORE it.
Nikita V. Youshchenko wrote:
Soon I will work on a linux kernel driver for a custom audio decoder device
that is being developed by a company I work for.
Kernel sound programming would be discussed on the alsa-devel list.
If not going into details, that devices reads A52-encoded stream
from
Christoph Kuhr wrote:
the last lines of the make command:
...
make[2]: Verlasse Verzeichnis
'/home/devel/SRC/alsa/alsa-driver-1.0.24+dfsg/pci'
make[1]: *** [dep] Fehler 1
make[1]: Verlasse Verzeichnis
'/home/devel/SRC/alsa/alsa-driver-1.0.24+dfsg'
make: *** [include/sndversions.h] Fehler 2
The
Christoph Kuhr wrote:
i compiled the alsa sources with the dummy otion,
now finished using it, how do i get rid of it?
Just don't use (load) it.
i tried to compile the sources without the dummy otion, but it didnt
work. (perhapes with an ice1724 option?)
What options did you use?
Regards,
Christoph Kuhr wrote:
Is there the possibility to run a hdsp card dummy?
The snd-dummy driver has a rme9652 model, but doesn't
simulate the mixer controls.
You might be able to modify dummy.c to better simulate
a hdsp.
Regards,
Clemens
___
Reid Fletcher wrote:
I have a couple of sound adapters labeled
Sek'd Prodif 96
They are known to be a good card. However I have been
unable to find any drivers for Linux for these.
sound/pci/Kconfig says:
| config SND_RME32
| tristate RME Digi32, 32/8, 32 PRO
| help
|
Rods Bobavich wrote:
USB interface is any one of the M-Audio Line. FastTrack USB, FastTrack Pro,
MobilePre USB... In other words multiple interfaces have been tested. This
problem is specific to this machine...
ALSA urb.c:480: frame 0 active: -75
Thank you for not mentioning this message on
Gordon JC Pearce wrote:
On Mon, 2011-01-31 at 21:55 -0800, farhan baluch wrote:
I am trying to read data from a usb microphone and using the pretty
standard method of using ioctl's to setup the sampling rate, channels,
bits and block size . This all works so the device is correctly setup.
Rory Filer wrote:
Even though I'm using I2S normal mode, it actually sounds a little more
recognizable (but not much better) if I switch to left-justified mode.
Switching between I²S and left-justified will exchange left/right.
Try using a stereo file with data on only one channel, and see if
Rory Filer wrote:
It took me all day Monday to figure out how to cross compile this for my
ARM platform and I even trashed my Ubuntu desktop in the process; that's
how I learned what the --prefix switch on the configure program does, lol.
For cross-compiling, use something like --prefix=/usr
Rory Filer wrote:
I've run out of ideas for things to try at the bottom end and now I
want to make sure my top-end components are working properly. This is
weird because I've stopped being able to hear anything lately, but a
scope confirms my I2S lines are all lit up.
And what exactly did you
Luis Garrido wrote:
So now I am throwing a powered USB hub in. As long as I keep it to
ALSA usage there is no problem: I can record and playback with, for
instance, Audacity using the ALSA backend. But anytime I try to launch
jackd the daemon fails and I get this in /var/log/messages:
cal wrote:
On 05/10/10 18:51, Arnout Engelen wrote:
Latency? Or jitter?
Not sure - possibly the main reason for the post was to seek help in resolving
fallacies in my thinking. With a jack period of 128, a midi event associated
with frame 129 won't actually get applied to audio generation
Gabriel M. Beddingfield wrote:
I've set alsa to wake me up every N frames.
Setting the period size makes this possible. The avail_min parameter
only prevents waveups when less than N frames are available.
However, when I awake, I find that I often have fewer than N frames
available:
Tim E. Real wrote:
On July 27, 2010 01:00:31 am you wrote:
Yikes! It's all coming back to me now, this can of worms.
In my case the Delta101LT card has the AK4524 ADCs.
The dB step of the IPGA stage is constant at 0.5dB, but the
dB step of the DATT stage is not - anywhere from 6dB to
Ralf Mardorf wrote:
On Wed, 2010-07-14 at 19:56 +0200, Arnout Engelen wrote:
On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf Mardorf wrote:
Yamaha DX7 -- Alesis D4 results in a 100% musical groove.
Yamaha DX7 -- PC -- Alesis D4 results in extreme latency
So here you're directly
Ralf Mardorf wrote:
- instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin
mentioned
This parameter will not have any effect on anything because there is no
program that uses the HPET timers from userspace. When high-resolution
timers are used by ALSA, this is done inside the
Robin Gareus wrote:
On 07/15/2010 01:07 PM, Ralf Mardorf wrote:
On Thu, 2010-07-15 at 12:55 +0200, Clemens Ladisch wrote:
Ralf Mardorf wrote:
dev.hpet.max-user-freq
This parameter will not have any effect on anything because there is no
program that uses the HPET timers from userspace
Ralf Mardorf wrote:
1.
I disconnected all audio connections for JACK and connected hw MIDI in
to hw MIDI out.
Is this connection through JACK or through ALSA, i.e., does it show up
in the output of aconnect -l? From what I understand, JACK's sample-
synchronous timing always adds latency,
Niels Mayer wrote:
On Mon, Jul 5, 2010 at 12:16 AM, Clemens Ladisch clem...@ladisch.de wrote:
As long we're optimizing for benchmarks: In recent enough kernel
versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control
MIDI Input Mode
## alias snd-card-5 snd-usb-audio
Adrian Knoth wrote:
latency distribution:
...
3.1 - 3.2 ms:1 #
...
3.9 - 4.0 ms:1 #
4.0 - 4.1 ms: 9903 ##
...
5.0 - 5.1 ms: 95 #
The default parameters of this tool are unrealistic; the next MIDI
command
James Morris wrote:
1) Notes of zero duration?
Are these legal MIDI?
Yes. There are synthesizers that can play percussion sounds at their
natural length and ignore note-off messages, so, sometimes, note-off
timing isn't available.
Do I send a note-on with simultaneous note-off?
Yes. Some
Julien Claassen wrote:
I was wondering, is there a difference in opening a device like
plughw:0,0
and
plug:pcm.my_own_device
If my_own_device is defined as a hw device, no.
I've looked in the code of aplay
aplay is more a debugging tool for driver than an example for application
Paul Davis wrote:
On Mon, Dec 14, 2009 at 2:45 PM, Stephen Sinclair radars...@gmail.com wrote:
As far as I understand
this doesn't happen as long as you stick to the word size of the
architecture. (Anyone please correct me if I'm wrong about that.)
unbelievably, perhaps, this was not
hollun...@gmx.at wrote:
hollun...@gmx.at wrote:
It seems I needed to modprobe snd-hrtimer
Now oom pretty much freezes as well when I tell it to use that,
Does oom or the entire system freeze?
Haven't tried this yet since I'm not sure it makes sense:
chgrp audio /dev/hpet
So even
hollun...@gmx.at wrote:
$ dmesg | grep -i hpet
Kernel command line:
root=/dev/disk/by-uuid/3e47466f-5ca1-499b-85fc-152074f36364 ro hpet=force
pci :00:11.0: Failed to force enable HPET
/dev/hpet was still created,
Then you have it. The message is probably because it doesn't need
to
Frank Neumann wrote:
snd_rawmidi_read(handle_in, NULL, 0); /* trigger reading */
So, a dummy read on the inbound connection gets it going.
Yes.
Any idea why this is necessary? buffer pre-warm?
The input port isn't enabled before the first read to allow the
application to reconfigure the
Jens M Andreasen wrote:
If you know that the device is virtual and that it won't pass on any
messages to the next device, you can sometimes get away with sending
usb-midi at a higher rate. This has to be implemented at the driver
level though.
This is handled by the USB protocol: the host
Jens M Andreasen wrote:
On Thu, 2009-10-08 at 09:26 +0200, Clemens Ladisch wrote:
This is handled by the USB protocol: the host controller retries sending
a data packet until the device acknowledges it. In other words, the
driver can blast away at the device with lots of packets
David Robillard wrote:
Not enough context quoted to tell; are the stops in Aeolus really too
complicated to be controlled via controllers and programs?
No: For 55 or so organ stops, you'd need 55 boolean controllers; this
can be easily done with NRPNs.
Best regards,
Clemens
Dave Phillips wrote:
wMaxPacketSize 0x0020 1x 32 bytes
are the same for the MidiSport and the UA25. However, there's a lot of
information from that report. Is there any other particularly relevant
data I should gather from lsusb ?
No, anything else wouldn't be visible in the
Dave Phillips wrote:
I've been experimenting with MIDI control from one machine to another. I
checked the timing of a single note played simultanesouly by instances
of QSynth on both machines and was surprised to hear a very noticeable
flamming. I then replaced the MidiSport 2x2 with my
Louis Gorenfeld wrote:
I can't post the source code, but I can post the algorithm: We have
input and output synched. The inputs are set to non-blocking behavior
while the outputs are not. The loop grabs input, and does any
processing it needs to. After that, it detects if any of the
Victor Lazzarini wrote:
Does anyone know anything about this change in alsa:
warning: snd_pcm_sw_params_set_xfer_align is deprecated (declared at
/usr/include/alsa/pcm.h:1115)
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=d948035a928400ae127c873fbf771389bee18949
Paul Davis wrote:
On Mon, Sep 7, 2009 at 10:54 AM, Clemens Ladischclem...@ladisch.de wrote:
Paul Davis wrote:
snd_pcm_write() and snd_pcm_read(), IIRC, allow readswrites of chunks
of data that are not period-sized.
Yes. So does snd_pcm_mmap_commit().
something must have changed. back in
Paul Davis wrote:
On Tue, Sep 8, 2009 at 2:39 AM, Clemens Ladischclem...@ladisch.de wrote:
Paul Davis wrote:
On Mon, Sep 7, 2009 at 10:54 AM, Clemens Ladischclem...@ladisch.de wrote:
Paul Davis wrote:
snd_pcm_write() and snd_pcm_read(), IIRC, allow readswrites of chunks
of data that are not
Paul Davis wrote:
if you use read/write, you deliver/receive the data to/from the kernel
at the time of calling. but there is then an extra buffer inside the
ALSA midlevel driver code that holds the data till it is needed (in
both directions).
There is no extra buffer for these functions;
Christian wrote:
snd_seq_client_info_malloc(clientInfo);
shared_ptrsnd_seq_client_info_t clientInfoMemoryHandler(clientInfo,
snd_seq_client_info_free);
Well the cleanUp methods are called at block-leaving.
I'm only a bit curious because after giving portInfo and clientInfo to
Christoph Eckert wrote:
I'm currently playing with some code that sends SysEx data to ALSA using
RtMidi¹. I get an error reported by the latter one as soon as the size of the
message exceeds 16355 bytes.
This probably exceeds ALSA's sequencer buffer size.
Can anyone comment whether this is
Renato Budinich wrote:
I would like to write a program which does the following:
detect the input events generated by a usb device which i own - the Rig
Kontrol 2 from Native Instruments which is a pedal board intended for
guitar use and which already has a linux driver - and trigger with
1 - 100 of 114 matches
Mail list logo
