The current code didn't proceed the text position buffer and the text
was always truncated in 12 bytes. Let's fix it.
Fixes: 74daf3a93a ("arecordmidi2: Add options to put meta data texts")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For convenience, add more options to embed the meta data texts given
via command line. The song name etc can be given directly via the
respective option directly, e.g. --song="text..."
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Allow to add arbitrary profile UMP data to be put into the
configuration of the recorded stream via --profile option.
The file must contain valid UMP data encoded in big-endian.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When the output file is '-', it's recorded to stdout.
For avoiding the corruption, this mode also suppresses the messages to
stdout, too, which can be enabled also via -s / --silent option.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit e609d66807.
It turned out that the failure was rather in alsa-lib API; the
input and output have been incorrectly implemented.
Now that the alsa-lib code got fixed, let's revert the bad fix.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now aplaymidi2 shows the meta data texts embedded in Flex Data
messages such as copyright and lyrics. The text output isn't
synchronized yet with the actual position, though.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recorded tick is incorrectly converted for 1us tempo-base on the
old kernels. Since we correct the queue tempo, we don't have to
adjust the returned tick value any longer. The current code applies
it doubly, resulting in 100 times slower.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The direction was wrongly passed to the FB setup. It has to be
"OUTPUT" instead of "INPUT, so that other applications can write to
arecordmidi2 port.
Fixes: 2cdf5ebedb ("arecordmidi2: Add initial version")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The queue should be started at the very same time of the start of the
stream itself in the interactive mode. Otherwise it'll get bogus long
waits until the start of the clip.
Move the code to start the queue in start_bar(), so that it's always
tied with the start sequence.
Fixes: 1205dd5f6c ("arecordmidi2: Add passive mode and interactive mode")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Allow arecordmidi2 running without specifying the source ports via -p
option. This will create a UMP Endpoint with the full 16 FBs, and
simply reads from the input ports via subscribers. User needs to
connect to the ports manually, though.
Also, add -r option to run in the interactive mode. In the
interactive mode, arecordmidi2 waits for the RETURN key entered from
the terminal to start the recording, and the recording ends after
another RETURN key.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
arecordmidi2 is a similar program like arecordmidi for recording the
incoming MIDI events, but storing in a MIDI Clip file for MIDI 2.0.
Most options are kept from arecordmidi, but some are dropped: namely,
the -l, -m and -f options are dropped for code simplicity.
Also -s option is dropped as well, as there is no need for split for
MIDI Clip file unlike SMF.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
aplaymidi2 is a program similar like aplaymidi, but intended for
playing back a MIDI Clip file that was introduced for handling UMP.
MIDI Clip file contains UMP packets, and its structure is much simpler
than SMF.
The options are mostly same as aplaymidi, but I omitted -l option for
simplifying the code.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
