#89 (and the associated release) broke semver and caused our builds to fail in CI.

Users are running into the same problem with fresh builds: see this Discord thread.

Please yank the release; and let us know if there's anything we can do to help out :)

MidiEvent::encode really needs documentation as to what it does.

From the signature and the implementation I can see that it returns (in case of success) the number of bytes consumed from the buffer as well as the encoded event (or None if no complete message was encoded).

Then it also needs to be documented that the event buffer is copied for long (sysex) messages. I guess this is because the documentation of snd_midi_event_encode states that

When this function returns a system exclusive sequencer event (ev->type is SND_SEQ_EVENT_SYSEX), the data pointer (ev->data.ext.ptr) points into the MIDI event parser's buffer. Therefore, the sequencer event can only be used as long as that buffer remains valid, i.e., until the next call to snd_midi_event_encode, snd_midi_event_encode_byte, snd_midi_event_resize_buffer, snd_midi_event_init, snd_midi_event_reset_encode, or snd_midi_event_free for that MIDI event parser.

This makes me wonder whether it might be possible to encode this in the Rust typesystem using lifetimes, instead of requiring a copy?

Furthermore, the documentation of snd_seq_event_input (where currently the data is also copied by Event::extract) has no such comment, which makes me wonder if the buffer there is managed by the event itself (because there is no separate underlying buffer).

I needed to get the card from a opened pcm, so I've added the snd_pcm_info to pcm.rs

I left out the nested structs for snd_pcm_class and snd_pcm_sync for now.

Hi @diwic !

I'd like to access PCMs from multiple threads (at least two) in order to:

• Only read/write buffers at real-time priority
• Gather PCM Status for timestamp / avail data at a specified frequency and at the highest real-time priority. The frequency should not depend on capture or playback frame sizes.

In order to do that, there will be three threads.

1. Capture thread
2. Playback thread
3. Timestamp/avail status gathering thread.

Therefore, both capture and playback PCMs need to be shared with the status gathering thread, that'll periodically adjust an asynchronous resampler ratio.

In alsa-lib tests, the pcm-multi-thread.c example shows how it is possible in C. It's simple, a single static snd_pcm_t *pcm is declared on top and all threads call methods on it.

Would it be possible to do that with alsa-rs? Right now, I get this error:

error[E0277]: the trait bound `*mut alsa_sys::snd_pcm_t: std::marker::Sync` is not satisfied in `&alsa::PCM`
   --> src/alsa_audio_time.rs:155:9
    |
155 |         thread::spawn(|| {
    |         ^^^^^^^^^^^^^ `*mut alsa_sys::snd_pcm_t` cannot be shared between threads safely

This is the first version of a PR that allows seq::Event to carry a reference to an external buffer for variable length data (esp. SysEx events). Without this, there is no way to use encode for SysEx messages and then send the message without creating an additional copy of the buffer. I removed the encode_cb variant, because it makes no sense: For the encoded event to be sent, it must contain a reference to the actual buffer. Actually, having a SysEx message that references an empty buffer (which was previously possible by returning None from the callback) is probably an error. ALSA forwards such an event unchecked, but the receiving application might not be able to deal with it.

I don't consider th e added lifetime for Event<'a> a big usability issue. IMHO it actually makes the API nicer compared to the callback variant. encode now takes the encoder (MidiEvent) by unique reference, so that the encoder can't be messed with while the event still references its buffer. This statically enforces that no method listed in the documentation for encode is called and the underyling buffer within the encoder remains unchanged while the event is alive.

The following changes could be added on top, but I didn't do it yet because I wanted to get feedbackfirst:

• event_input could be changed in a similar way to encode, coupling the returned event's lifetime to the Seq instance by taking &mut Seq. In this case, the input buffer of the sequencer instance is directly referenced, and it's not very well documented under what circumstances that buffer might change. Not allowing any method call on Seq while the event is alive should be enough, however, but might be too much, because e.g. you wouldn't be able to call event_output directly after event_input to forward the event to another port.

• It is desirable to be able to create an Event<'a> directly from a &'a [u8], i.e. a SysEx message that references a buffer managed by the user, without creating a copy. (Update: I have added another commit (the second one) to implement this. Feel free to reject that commit.)

Update: I have also added a third commit that fixes a preexisting bug that is not directly related to my changes.

I got a bug report on my DSP project, where it panics when reading the state of a pcm. The panic comes from here : https://github.com/diwic/alsa-rs/blob/master/src/pcm.rs#L159 I'm guessing the card returns an invalid value for the state, but it doesn't happen with any of the hardware I have so I can't check that. Anyway, would it be an option to add an "Invalid" or "Unknown" state variant to avoid a panic with misbehaving hardware? Or let state() return a Result? I can implement something and make a PR, but let's agree on the ifs and how's first :)

alsa::pcm::PCM::open (pcm.rs:135) due to (as far as i can tell) the variable 'r' being 0x0

I'm not sure how to proceed, the program i've been using to narrow it down was this from the synth-example

fn main() {
    let args: Vec<_> = std::env::args().collect();
    let req_devname = format!("hw:{}", args[1]);
    let p = alsa::PCM::new(&req_devname, alsa::Direction::Playback, false);
 }

Might it be an issue from alpine using musl?

Hi @diwic! Thanks a lot for the great work on this crate, it's really useful.

For the MultiDSP project, I'm researching the best way to implement an asynchronous resampler that'll keep multiple sound cards in sync.

The best way seems to be leveraging the PCM status delay, avail and timestamps. It is already possible to query that today but the timestamps seem to always of the default type: DMA. For the use case of sound card synchronization, the link time and analog times are useful as well. Documentation: https://www.kernel.org/doc/html/latest/sound/designs/timestamping.html

I rewrote in Rust alsa_time.c from alsa-lib for experimentation and am now testing from that.

Is timestamp type support something you're interested adding? If I should implement it myself, would you have recommendations?

This is a follow-up after #16, because I took some time now to look at it. And I'm impressed, the current version contains almost everything that I needed, awesome work! :+1:

I'm missing only one function: snd_seq_control_queue. Actually I'm using snd_seq_start_queue and snd_seq_stop_queue, but those are defined as macros in the original API (wrapping snd_seq_control_queue). Maybe you can create functions for them also.

I've added snd_mixer_selem_set_playback_dB

This function uses dir to select direction (-1 = accurate or first bellow, 0 = accurate, 1 = accurate or first above). I've added an enum for this called AccuracyDirection but there is also a ValueOr enum in lib.rs. Should I use ValueOr for this function too?

Hello again! Here are the changes to alsa-rs which correspond to this commit in diwic/alsa-sys.

Thanks once more for all your work on these libraries — I really appreciate it! :grinning: