Add support for OpenBSD platform via sndio host #493

AaronM04 · 2020-10-30T04:59:36Z

This adds support for the sndio host which is the default and only supported host on OpenBSD. I have tested all the examples for cpal and rodio, with no issues observed. If there are any improvements needed to bring this PR up to the standards of the cpal project, please let me know. :-)

mitchmindtree · 2020-10-30T12:13:52Z

Thanks for the epic PR @AaronM04!

I don't have time to dig into this myself at the moment, not to mention my lack of experience with sndio & OpenBSD, however two steps that would help to land this are:

Having one or more other OpenBSD users review and test the examples. I don't know of any other OpenBSD users personally, but if any are reading this it would help a lot if you could test and review!
Adding a job to the Github CI workflow for OpenBSD + sndio. I'm not sure off the top of my head if it's possible to spin up a OpenBSD instance as easily as it is say Ubuntu. If it turns out not to be feasible with the github workflow, perhaps you have another recommendation for OpenBSD-specific CI? That said, I'd prefer we get this working with the github workflow in order to keep managing CI as simple as possible for maintainers.

blackgnezdo

Responding to review request since I happen to care about OpenBSD and Rust :)

The change is fairly massive so I didn't make it all the way to the end. Depending on your motivation and the prevailing conventions of RustAudio, some comments may be too nit-picky.

src/host/sndio/adapters.rs

src/host/sndio/endian.rs

src/host/sndio/mod.rs

blackgnezdo · 2020-11-02T06:15:11Z

src/host/sndio/mod.rs

+    /// Buffer overrun/underrun behavior -- ignore/sync/error?
+    behavior: BufferXrunBehavior,
+
+    /// If a buffer size was chosen, contains that value.


The abundance of Optional suggests a huge state space. I suspect it can be reduced by refactoring InnerState type into an enum with a pruned set of fields that apply to specific stages of of the state machine.

@blackgnezdo I have fixed this. Please take a look when you get a chance. Thanks!

src/host/sndio/mod.rs

blackgnezdo · 2020-11-02T06:17:45Z

src/host/sndio/mod.rs

+        let hdl = unsafe {
+            // The transmute is needed because this C string is *const u8 in one place but *const i8 in another place.
+            let devany_ptr = mem::transmute::<_, *const i8>(sndio_sys::SIO_DEVANY as *const _);
+            let nonblocking = true as i32;


This might as we be written as 1 with an increase in readability, what do you think?

Maybe. I tend to favor boolean values as Rust bools, though the cast may be too confusing here.

blackgnezdo · 2020-11-02T06:18:52Z

src/host/sndio/mod.rs

+            )
+        };
+        if hdl.is_null() {
+            return Err(SndioError::DeviceNotAvailable);


Can you do better and somehow report the errno? Probably applies everywhere.

I can try that here but when I checked errno for an error from sio_setpar it didn't set it.

src/host/sndio/mod.rs

blackgnezdo · 2020-11-02T06:49:20Z

Adding a job to the Github CI workflow for OpenBSD + sndio. I'm not sure off the top of my head if it's possible to spin up a OpenBSD instance as easily as it is say Ubuntu. If it turns out not to be feasible with the github workflow, perhaps you have another recommendation for OpenBSD-specific CI? That said, I'd prefer we get this working with the github workflow in order to keep managing CI as simple as possible for maintainers.

I don't know what it would take to get an OpenBSD CI on github, but as a point of reference, here's what it takes to get a GCE image of OpenBSD.
https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh

grayed · 2020-11-03T06:30:22Z

Adding a job to the Github CI workflow for OpenBSD + sndio. I'm not sure off the top of my head if it's possible to spin up a OpenBSD instance as easily as it is say Ubuntu. If it turns out not to be feasible with the github workflow, perhaps you have another recommendation for OpenBSD-specific CI? That said, I'd prefer we get this working with the github workflow in order to keep managing CI as simple as possible for maintainers.

FWIW, the sndio library is available on Linux, so you don't need OpenBSD to run CI for it: https://sndio.org/

AaronM04 · 2020-11-06T04:53:28Z

For CI, I think it will be more practical to use sndio on Linux (as @grayed mentioned) than to setup an OpenBSD VM as part of the github workflow. The one potential complication is getting sndio-sys as a dependency on linux, but only conditionally. Currently the dependency is conditional on cfg(target_os = "openbsd"). I am not very familiar with this part of Cargo/Rust so I would be very grateful for any assistance with this.

As for testing the workflow, should I just push to this branch? (it could be a lot of commits if it's trial and error that way)

mitchmindtree · 2020-11-06T13:54:52Z

The one potential complication is getting sndio-sys as a dependency on linux, but only conditionally.

Perhaps we can add a linux-sndio cargo feature, and then conditionally include the sndio host with a cfg that looks something like:

#[cfg(or(target_os = "openbsd", and(target_os = "linux", feature = "linux-sndio")))]

@RustAudio/cpal-maintainers does this sound OK?

As for testing the workflow, should I just push to this branch? (it could be a lot of commits if it's trial and error that way)

Yeah that's totally fine, though perhaps rather than continuously adding new commits you could use git commit --amend on the last commit that adds the workflow and then force push it on each attempt? This is what I normally do when attempting to add a new workflow at least, not sure if there's a nicer way!

blackgnezdo

I noted a few more things, but the whole change is too big to read in one sitting :(

Also, there's a bunch of CI generated complaints that probably need to be addressed.

blackgnezdo · 2020-11-23T04:58:43Z

src/host/sndio/mod.rs

+
+    fn open(&mut self) -> Result<(), SndioError> {
+        match self {
+            InnerState::Opened { .. } | InnerState::Running { .. } => Ok(()), // Already opened


Why is it a good idea to permit a duplicate open? I'd complain and return an SndioError.

blackgnezdo · 2020-11-23T05:03:36Z

src/host/sndio/mod.rs

+                // Transition to running
+                par.appbufsz = buffer_size as u32;
+                hdl.set_params(&par)?;
+                let mut tmp: HashMap<u32, sndio_sys::sio_par> = HashMap::new();


Does turbo-fish not work here? It should be shorter.

blackgnezdo · 2020-11-23T05:06:24Z

src/host/sndio/mod.rs

+        hdl: SioHdl,
+
+        /// Map of sample rate to parameters.
+        sample_rate_to_par: HashMap<u32, sndio_sys::sio_par>,


HashMap<u32, sndio_sys::sio_par> type seems pervasive. It probably deserves a well-named alias or even a newtype. I'm also partial to creating aliases for numeric types such that a sample rate and every other kind of u32 aren't easy to mix-up. Between these two, I'd probably have here:

rate_parameters: RateParameterMap,

src/host/sndio/mod.rs

+unsafe impl Send for SioHdl {}
+
+/// The shared state between Device and Stream. Responsible for closing handle when dropped.
+enum InnerState {


blackgnezdo · 2020-11-23T05:09:13Z

src/host/sndio/mod.rs

+
+unsafe impl Send for SioHdl {}
+
+/// The shared state between Device and Stream. Responsible for closing handle when dropped.


Maybe this should also list the permitted transitions unless they are fully controlled by the type impl?

blackgnezdo · 2020-11-23T05:13:33Z

src/host/sndio/mod.rs

+    }
+}
+
+unsafe impl Send for SioHdl {}


Probably deserves a comment explaining unsafe: why it has to be unsafe, also why and under which assumptions it's OK.

blackgnezdo · 2020-11-23T05:22:29Z

src/host/sndio/mod.rs

+
+        inner_state.setup_stream(config)?;
+
+        let idx;


Combine declaration with assignment.

blackgnezdo · 2020-11-23T05:25:56Z

src/host/sndio/mod.rs

+    }
+
+    pub fn set_xrun_behavior(&mut self, b: BufferXrunBehavior) -> Result<(), SndioError> {
+        let mut inner_state = self.inner_state.lock().unwrap();


Since there's a way to return an error, why unwrap rather than complain? Seems to apply in all the cases below.

I did it this way because only panics on the previous thread to have locked the mutex can cause an error to be returned from lock. I suppose it still makes sense to return a "thread panicked" error here.

blackgnezdo · 2020-11-23T05:30:40Z

src/host/sndio/mod.rs

+    }
+
+    /// Create an output stream.
+    fn build_output_stream_raw<D, E>(


Looks like 50 lines of code largely similar to build_input_stream_raw, any chance you can figure out the common parts and de-dup?

I spent a lot of time trying this out and unfortunately I don't think this can be de-duped without adding another layer of Box around the callbacks, which would impact performance (albeit not by much).

(well, there are macros but that feels almost like obfuscating the code to me)

blackgnezdo · 2020-11-23T05:32:49Z

src/host/sndio/mod.rs

+
+fn supported_config_from_par(par: &sndio_sys::sio_par, num_channels: u32) -> SupportedStreamConfig {
+    SupportedStreamConfig {
+        channels: num_channels as u16,


Would this be a true comment to add? Otherwise it's not clear why u32 suddenly becomes u16.
// Conversion is courtesy of type mismatch between sndio and RustAudio.

Yes, added verbatim!

* Add SampleRateMap with SampleRate keys rather than raw HashMap with u32 keys. * Use FrameCount type alias rather than usize for buffer size. * More robust error handling. * Document InnerState state transitions.

AaronM04 · 2020-12-23T05:29:07Z

@blackgnezdo I finally was able to return to this. Please review when you have time. Thanks in advance! 😄

BTW I don't know what CI complaints you are referring to.

blackgnezdo

@AaronM04, I wanted to play with the code but cargo build fails for me on openbsd-amd64-current:

   Compiling sndio-sys v0.0.1
error: failed to run custom build command for `sndio-sys v0.0.1`

Caused by:
  process didn't exit successfully: `/home/greg/s/cpal/target/debug/build/sndio-sys-c905c01512cca331/build-script-build` (exit code: 101)
  --- stdout
  cargo:rustc-link-lib=sndio
  cargo:rerun-if-changed=wrapper.h

  --- stderr
  thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any valid shared libraries matching: [\'libclang.so\', \'libclang.so.*\'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"', /home/greg/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.3/src/lib.rs:1956:31
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Any clues?

src/host/sndio/mod.rs

AaronM04 · 2021-01-20T04:12:45Z

Somehow I missed the notification for this. :/

@AaronM04, I wanted to play with the code but cargo build fails for me on openbsd-amd64-current:

   Compiling sndio-sys v0.0.1
error: failed to run custom build command for `sndio-sys v0.0.1`

Caused by:
  process didn't exit successfully: `/home/greg/s/cpal/target/debug/build/sndio-sys-c905c01512cca331/build-script-build` (exit code: 101)
  --- stdout
  cargo:rustc-link-lib=sndio
  cargo:rerun-if-changed=wrapper.h

  --- stderr
  thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any valid shared libraries matching: [\'libclang.so\', \'libclang.so.*\'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"', /home/greg/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.3/src/lib.rs:1956:31
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Any clues?

Did it work back in November but not anymore? If so, I have no idea what the issue is.

If this is the first time you're trying to build it, run:

doas pkg_add llvm

I added this to https://github.com/mjkillough/sioctl-rs#installation

…usize

…io_host

AaronM04 · 2021-01-27T05:52:27Z

The iOS build is failing but I suspect this is not due to any of my commits.

blackgnezdo · 2021-01-27T06:32:16Z

Somehow I missed the notification for this. :/
...

Any clues?

Did it work back in November but not anymore? If so, I have no idea what the issue is.

No, I had never tried to build your code before the first time I complained.

If this is the first time you're trying to build it, run:
doas pkg_add llvm
I added this to https://github.com/mjkillough/sioctl-rs#installation

I do have llvm package:

% pkg_info llvm
Information for inst:llvm-10.0.1p8
...

The library is available on the system:

% pkg_info -L llvm | grep 'libclang.*so'
...
/usr/local/lib/libclang-cpp.so.0.0
/usr/local/lib/libclang.so.8.1

Yet cargo build reports (for d419f0f):

  Compiling sndio-sys v0.0.1
error: failed to run custom build command for `sndio-sys v0.0.1`

Caused by:
  process didn't exit successfully: `/home/greg/s/cpal/target/debug/build/sndio-sys-cbc09558b43ecb1b/build-script-build` (exit code: 101)
  --- stdout
  cargo:rustc-link-lib=sndio
  cargo:rerun-if-changed=wrapper.h

  --- stderr
  thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any valid shared libraries matching: [\'libclang.so\', \'libclang.so.*\'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"', /home/greg/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.3/src/lib.rs:1956:31
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Now, I bothered to read the error message and the resolution of my problem is:

% LIBCLANG_PATH=/usr/local/lib/libclang.so.8.1 cargo build
   Compiling sndio-sys v0.0.1
   Compiling cpal v0.12.1 (/home/greg/s/cpal)
    Finished dev [unoptimized + debuginfo] target(s) in 7.29s

I wonder why you don't have to set LIBCLANG_PATH.

AaronM04 · 2021-01-27T15:24:18Z

I wonder why you don't have to set LIBCLANG_PATH.

It turns out that I added export LIBCLANG_PATH=/usr/local/lib to my profile and forgot about it...

blackgnezdo · 2021-01-30T05:48:03Z

I proposed some code shrinking changes a minor refactoring. If this works, I can massage it a bit more.

Avoids duplicating information with: * TypeSampleFormat to avoid redundant values * Sample trait for value conversion * Common data_from_vec fn Indexing typically means a runtime check whereas iterators don't.

AaronM04 · 2021-02-01T20:43:28Z

@blackgnezdo thanks! It is quite an improvement. I merged your commits into this branch.

Done with editing Cargo.toml followed by `cargo update -p cpal`, which, sadly, change a whole bunch of other dependencies. This makes audio play, but two issues remain: 1. Playback speed is noticably slow. 2. Toggling play -> shows this error, although playback is successfully paused: ``` [2021-11-17T16:03:04Z ERROR psst_core::audio::output] failed to stop stream: A backend-specific error has occurred: pausing is not implemented ``` "Add support for OpenBSD platform via sndio host" RustAudio/cpal#493 is based on an older cpal release; maybe rebasing on top of HEAD and therefore bringing in the cpal changes that current psst already uses helps with/fixes any of the two issues?

klemensn · 2021-11-18T19:50:51Z

Hi everyone!

Over at jpochyla/psst#191 psst switched to cpal and I'm working on OpenBSD support.
I'm using your feature branch to be able to play music at all, but unfortunately playback speed is noticably slow.
(before cpal, miniaudio was used and psst played music just fine on OpenBSD.)

My audio/rust/cpal/etc. foo is weak, hence I've only been testing cpal with psst.
Can you recommend another (possibly simpler) way of testing cpal's sndio support in this branch?
I'd like to help bring this forward in whatever way I can.

I've also rebased your branch onto latest cpal master and retested psst, but with no avail: playback speed is still too slow.

AaronM04 · 2021-11-19T04:28:18Z

Hey @klemensn ! 👋

Can you define "slow"? Which of these is it?

Stretched out/longer notes but the same pitch. A 4 minute song takes >4 minutes to play.
Lower pitch. A 4 minute song takes >4 minutes to play. If so, it could be that psst is expecting one sample rate but cpal is using another one.
Stuttering/choppy playback.

Lastly, is this an OpenBSD-specific problem with psst+cpal? I suspect not, but I just wanted to be sure.

EDIT: have you tried the example cpal programs on OpenBSD? What happens with those?

klemensn · 2021-11-23T22:49:07Z

psst reports 31 seconds of elapsed playback time while 60 seconds have passed
on the wall clock.

No other issues like stuttering or so, just playback speed.

Here are the outputs of cpal's examples built with cargo build --examples.
beep produces a since, but I don't know which frequency (the source code did
not immediately give away this information).

$ ./target/release/examples/feedback
Using input device: "sndio default device"
Using output device: "sndio default device"
Attempting to build both streams with f32 samples and `StreamConfig { channels: 1, sample_rate: SampleRate(48000), buffer_size: Default }`.
Successfully built streams.
Starting the input and output streams with `150` milliseconds of latency.
Playing for 3 seconds... 
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
input stream fell behind: try increasing latency
Done!

$ ./target/release/examples/enumerate
Supported hosts:
  [Sndio]
Available hosts:
  [Sndio]
sndio
  Default Input Device:
    Some("sndio default device")
  Default Output Device:
    Some("sndio default device")
  Devices: 
  1. "sndio default device"
    Default input stream config:
      SupportedStreamConfig { channels: 1, sample_rate: SampleRate(48000), buffer_size: Range { min: 480, max: 4800 }, sample_format: I16 }
    All supported input stream configs:
      1.1. SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 480, max: 4800 }, sample_format: I16 }
      1.2. SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(8000), max_sample_rate: SampleRate(8000), buffer_size: Range { min: 80, max: 800 }, sample_format: I16 }
      1.3. SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(44100), max_sample_rate: SampleRate(44100), buffer_size: Range { min: 441, max: 4410 }, sample_format: I16 }
    Default output stream config:
      SupportedStreamConfig { channels: 1, sample_rate: SampleRate(48000), buffer_size: Range { min: 480, max: 4800 }, sample_format: I16 }
    All supported output stream configs:
      1.1. SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 480, max: 4800 }, sample_format: I16 }
      1.2. SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(8000), max_sample_rate: SampleRate(8000), buffer_size: Range { min: 80, max: 800 }, sample_format: I16 }
      1.3. SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(44100), max_sample_rate: SampleRate(44100), buffer_size: Range { min: 441, max: 4410 }, sample_format: I16 }

$ ./target/release/examples/beep
Output device: sndio default device
Default output config: SupportedStreamConfig { channels: 1, sample_rate: SampleRate(48000), buffer_size: Range { min: 480, max: 4800 }, sample_format: I16 }

klemensn · 2021-11-24T11:14:30Z

FWIW, recording through cpal works correctly on OpenBSD.
aucat(1) plays the file in the correct speed, without problems.

$ ./target/release/examples/record_wav
Input device: sndio default device
Default input config: SupportedStreamConfig { channels: 1, sample_rate: SampleRate(48000), buffer_size: Range { min: 480, max: 4800 }, sample_format: I16 }
Begin recording...
Recording /home/kn/src/cpal/recorded.wav complete!

$ aucat -i /home/kn/src/cpal/recorded.wav

AaronM04 · 2021-11-24T17:45:31Z

@klemensn the beep example is a 440 Hz sine wave.

I see the same output as you for the feedback and enumerate examples (including the input stream fell behind: try increasing latency lines).

Try talking during the feedback example. Does your echoed voice sound normal?

I'll try it out with psst if I get some more time today.

AaronM04 · 2021-11-24T19:20:26Z

@klemensn I tried compiling psst after making it use the cpal from this branch, and I got this error from the souvlaki crate:

error[E0308]: mismatched types
  --> /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/souvlaki-0.4.0/src/platform/empty/mod.rs:13:9
   |
12 |     pub fn new(_config: PlatformConfig) -> Result<Self, Error> {
   |                                            ------------------- expected `Result<platform::platform::MediaControls, platform::platform::Error>` because of return type
13 |         Self
   |         ^^^^
   |         |
   |         expected enum `Result`, found struct `platform::platform::MediaControls`
   |         help: try using a variant of the expected enum: `Ok(Self)`
   |
   = note: expected enum `Result<platform::platform::MediaControls, platform::platform::Error>`
            found struct `platform::platform::MediaControls`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `souvlaki` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

Did you encounter this error? If so, how did you fix it? Thanks.

Also, did you do anything nontrivial when updating this branch to cpal 0.13?

klemensn · 2021-11-24T22:57:16Z

Use my openbsd branch from jpochyla/psst#191 to build
on OpenBSD, it contains all quirks, incl. an update to souvlaki where I fixed
the error you ran into.

Speaking during the feedback example plays back as expected, i.e. without any
slow down, pitch or anything else.

Thanks for looking into this!

AaronM04 · 2021-11-29T21:29:29Z

@klemensn I was able to reproduce the issue with your psst branch (I did make one change to a Cargo.toml to use my local cpal repository though). I played a song I am familiar with and the voices sounded very low pitch (stretched out). I think it is either a sample-rate confusion or a stereo-mono confusion.

I also noticed an error when hitting pause:

[2021-11-29T21:14:24Z ERROR psst_core::audio::output] failed to stop stream: A backend-specific error has occurred: pausing is not implemented

This suggests two things need to be fixed in this branch before psst will be working with cpal on OpenBSD:

Fix the sample-rate or stereo-mono confusion. An example of the latter would be psst requesting stereo playback but cpal using mono -- this would cause everything to be one octave lower (half the frequency).
~~Implement pause/resume. Essentially the sndio system needs to be closed and re-created.~~ EDIT: playback continues when I unpause, inexplicably! Maybe we don't need to fix this

Unfortunately, my time is over-committed so I can't take the lead in fixing these. However, I can definitely help another Rust developer understand the code that I wrote. I can also suggest where to do debugging or add print statements to better understand this.

Done with editing Cargo.toml followed by `cargo update -p cpal`, which, sadly, change a whole bunch of other dependencies. This makes audio play, but two issues remain: 1. Playback speed is noticably slow. 2. Toggling play -> shows this error, although playback is successfully paused: ``` [2021-11-17T16:03:04Z ERROR psst_core::audio::output] failed to stop stream: A backend-specific error has occurred: pausing is not implemented ``` "Add support for OpenBSD platform via sndio host" RustAudio/cpal#493 is based on an older cpal release; maybe rebasing on top of HEAD and therefore bringing in the cpal changes that current psst already uses helps with/fixes any of the two issues?

klemensn · 2021-11-30T00:40:38Z

@AaronM04 Thanks a bunch!

@jpochyla just committed further changes, specifically
jpochyla/psst@a774653
jpochyla/psst@df89890
which I rebased onto.

Something's still off as you can see in
jpochyla/psst@a4faacb
but playback speed is normal now and I can properly listen to songs!

So it seems as if @jpochyla followed your suggestion to fix "stereo-mono confusion".

The pause issue you mentioned is known (to me); I have not done anything yet to fix it.
Pausing does work, though, as does resuming playback.

Done with editing Cargo.toml followed by `cargo update -p cpal`, which, sadly, change a whole bunch of other dependencies. This makes audio play, but two issues remain: 1. Playback speed is noticably slow. 2. Toggling play -> shows this error, although playback is successfully paused: ``` [2021-11-17T16:03:04Z ERROR psst_core::audio::output] failed to stop stream: A backend-specific error has occurred: pausing is not implemented ``` "Add support for OpenBSD platform via sndio host" RustAudio/cpal#493 is based on an older cpal release; maybe rebasing on top of HEAD and therefore bringing in the cpal changes that current psst already uses helps with/fixes any of the two issues?

midnadimple-zz · 2022-04-22T05:34:37Z

just wanting to ping this request. i've tested it on my own repo. it fully merges into master and the examples run well. this should be noticed

AaronM04 · 2022-04-22T05:47:35Z

Hi @midnadimple . Thanks for the ping.

I think what this needs is another developer familiar with Rust, because I don't have much time to spend on this unfortunately.

There's only a bit of work left:

Resolve the conflict (yes, there is one).
Get another code review, and address any review feedback.
Make sure tests pass
Merge it

AaronM04 added 2 commits October 29, 2020 21:53

Add support for OpenBSD platform via sndio host

2abb970

Restore incorrectly modified line in asio-sys build-deps

37600dd

blackgnezdo reviewed Nov 2, 2020

View reviewed changes

AaronM04 added 2 commits November 5, 2020 20:58

sndio: refactor adapters

07ceda7

sndio: simpler endianness check

8e7227b

AaronM04 added 3 commits November 8, 2020 18:15

sndio: simplify Devices iterator

7f11fd1

rustfmt fix

2e0c63b

sndio: avoid unsafe impl Send on InnerState

eeafe6f

AaronM04 force-pushed the aaron/openbsd_sndio_host branch from d426f69 to eeafe6f Compare November 12, 2020 05:55

sndio: refactor InnerState to be enum (reduce the Options and unwraps)

47877cf

blackgnezdo reviewed Nov 23, 2020

View reviewed changes

sndio: address feedback from code review

51d3486

* Add SampleRateMap with SampleRate keys rather than raw HashMap with u32 keys. * Use FrameCount type alias rather than usize for buffer size. * More robust error handling. * Document InnerState state transitions.

blackgnezdo reviewed Dec 30, 2020

View reviewed changes

src/host/sndio/mod.rs Show resolved Hide resolved

AaronM04 added 2 commits January 26, 2021 20:21

sndio: change input/output_callbacks storage to a HashMap indexed by …

d419f0f

…usize

Merge remote-tracking branch 'upstream/master' into aaron/openbsd_snd…

ce57c56

…io_host

AaronM04 force-pushed the aaron/openbsd_sndio_host branch from ae8d7b8 to b344503 Compare January 27, 2021 06:01

sndio: test CI with linux-sndio feature

2e00be6

AaronM04 force-pushed the aaron/openbsd_sndio_host branch from b344503 to 2e00be6 Compare January 27, 2021 06:06

blackgnezdo added 2 commits January 28, 2021 21:37

Wrap (usize, HashMap) into a struct

842069b

Shrink input_adapter_callback by parametrizing by type

96a7447

Add TypeSampleFormat - type-level counterpart to SampleFormat

aefb585

blackgnezdo and others added 3 commits January 29, 2021 22:01

Deduplicate output_adapter_callback and avoid indexing

f64997d

Avoids duplicating information with: * TypeSampleFormat to avoid redundant values * Sample trait for value conversion * Common data_from_vec fn Indexing typically means a runtime check whereas iterators don't.

Deduplicate config_ranges

2a068cc

cargo fmt

ddd08e3

This was referenced Oct 14, 2021

Support OpenBSD jpochyla/psst#191

Closed

Switch to CPAL, Symphonia, and parking_lot jpochyla/psst#197

Merged

Merge branch 'master' into aaron/openbsd_sndio_host

bd1da41

klemensn mentioned this pull request Jan 15, 2024

Default to PortAudio backend on non-Linux Spotifyd/spotifyd#1257

Draft


		unsafe impl Send for SioHdl {}

		/// The shared state between Device and Stream. Responsible for closing handle when dropped.

Add support for OpenBSD platform via sndio host #493

Are you sure you want to change the base?

Add support for OpenBSD platform via sndio host #493

Conversation

AaronM04 commented Oct 30, 2020

mitchmindtree commented Oct 30, 2020

blackgnezdo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blackgnezdo commented Nov 2, 2020

grayed commented Nov 3, 2020

AaronM04 commented Nov 6, 2020

mitchmindtree commented Nov 6, 2020

blackgnezdo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as resolved.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AaronM04 commented Dec 23, 2020

blackgnezdo left a comment

Choose a reason for hiding this comment

AaronM04 commented Jan 20, 2021

AaronM04 commented Jan 27, 2021

blackgnezdo commented Jan 27, 2021

AaronM04 commented Jan 27, 2021

blackgnezdo commented Jan 30, 2021

AaronM04 commented Feb 1, 2021

klemensn commented Nov 18, 2021

AaronM04 commented Nov 19, 2021 • edited Loading

klemensn commented Nov 23, 2021

klemensn commented Nov 24, 2021

AaronM04 commented Nov 24, 2021

AaronM04 commented Nov 24, 2021 • edited Loading

klemensn commented Nov 24, 2021

AaronM04 commented Nov 29, 2021 • edited Loading

klemensn commented Nov 30, 2021

midnadimple-zz commented Apr 22, 2022

AaronM04 commented Apr 22, 2022

AaronM04 commented Nov 19, 2021 •

edited

Loading

AaronM04 commented Nov 24, 2021 •

edited

Loading

AaronM04 commented Nov 29, 2021 •

edited

Loading