Giter VIP home page Giter VIP logo

rainout's People

Contributors

billydm avatar secondflight avatar topisani avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

rainout's Issues

Comments on DESIGN_DOC.md

As of 705d2f

Enumeration

  • Maybe the backend could be described and selected as an enum? All variants should be available in the enum regardless if support for them is compiled in (unlike how it is in CPAL).
  • Not in the design doc or API, but affects library usage: I don't think the backends should be split according to OS. In other words, I don't think the OS should be the sole discriminant of which backends are compiled in, because library users may want to configure that somehow, especially with hard-to-compile ones like ASIO. Instead I think we should dispatch directly to each specific backend if it is compiled.
  • Returning all device info for all backends at once seems problematic. Some backends may take a while to "start up" and enumerate devices. Some may even hang in some cases.
    • There are also some nasty details with trying to get all of that info beforehand. I think in ALSA, there isn't really a "maximum" channel count, you just have to test a configuration and see if it works.
    • With JACK, we could provide the names of the system ports, but this doesn't limit the amount of ports that can be opened. There's also not much sense in supplying a "maximum" amount of port names โ€“ it would either be an arbitrary limit or the default 256. The idea of giving port names as strings in Config makes sense for JACK though, because the port names can also be customized, same as the client name.
    • What happens if the set of available devices changes between enumeration and startup? It might be possible to accidentally try to open a completely different device, since they are only correlated by name.
      • Finding the device with a specific name when starting up likely requires iterating over all devices in the backend again.
      • ALSA is an exception: the name can also be something else which was not enumerated, because it can have various parameters and aliases. Is this explicitly supported by the library, or should the name always be one of the enumerated ones?

Configuration

  • Set this to None to automatically select the default port layout for the device.

    I think there should be an option to skip input/output functionality. Or is that indicated by an empty vector?

  • The MIDI part of the API probably needs more fleshing out still.

    • Should connecting to devices from different backends be supported?
    • In ALSA/Jack we can create anonymous clients that aren't necessarily tied to any available device.
    • I suppose changing the MIDI config on the fly should also be allowed?
      • Unplugging/hotplugging are things to possibly consider

Startup/run

  • Is the tuple necessary here instead of Variant(u32, u32)?
    TryNextBestWithMinMaxSR((u32, u32)),
    TryNextBestWithMinMaxSize((u32, u32)),
  • Reporting estimated round-trip latency mainly serves to inform the end-user with a ballpark estimate. Sometimes that is all you can do of course, but some kind of timestamps are needed to properly correlate MIDI/other events with the audio clock.

Wild idea

Doing input and output syncrhonized in the same callback prevents a certain feature that may or may not be desired.

When recording, it is often more important that the recording is flawless, while the live playback (through effects and such) is less important and if it does have dropouts, there's not much that can be done about it. If input and output are instead run asynchronous of each other, it is possible to always keep recording without dropouts regardless of how slowly the effects chain is running.

More specifically, we could have it so that the input side runs on schedule and sends data to be stored on disk (or memory), and also sends it to the output side for further processing. The output side can then slow down and drop out as much as it likes without affecting the input side.

Something akin to this is provided by JACK2 asynchronous mode, though the recording would have to happen in a separate client from the effects. With JACK, it is explicitly stated that asynchronous mode increases latency by one period. Some additional latency is inevitable, so I suppose this should be configurable.

Earlier I thought this might be a common feature in DAWs, but my experience might have been incidental. Even with synchronized I/O, there is some room for the output to drop out before any input data is lost. From what I was able to test (and read code), none of Bitwig, Ardour or Reaper have this feature. So I guess we can happily ignore it.

`rusty-daw-io` doesn't build on Windows

rusty-daw-io currently doesn't build for me.

Steps to reproduce:

  1. Clone the repo
  2. Run cargo build
Logs (click to expand)
PS Code\rusty-daw\rusty-daw-io> cargo build
   Compiling rusty-daw-io v0.0.0 (C:\Users\qbgee\Documents\Code\rusty-daw\rusty-daw-io)
error[E0432]: unresolved imports `super::AudioServerConfig`, `super::BufferSizeInfo`, `super::MidiServerConfig`, `super::StreamError`
 --> src\windows\mod.rs:4:5
  |
4 |     AudioServerConfig, AudioServerInfo, BufferSizeInfo, MidiServerConfig, MidiServerInfo,
  |     ^^^^^^^^^^^^^^^^^                   ^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^ no `MidiServerConfig` in the root
  |     |                                   |
  |     |                                   no `BufferSizeInfo` in the root
  |     no `AudioServerConfig` in the root
5 |     OsDevicesInfo, OsStreamHandle, RtProcessHandler, SpawnRtThreadError, StreamError, StreamInfo,
  |                                                                          ^^^^^^^^^^^ no `StreamError` in the root
  |
help: a similar name exists in the module
  |
4 |     AudioServerInfo, AudioServerInfo, BufferSizeInfo, MidiServerConfig, MidiServerInfo,
  |     ~~~~~~~~~~~~~~~
help: a similar name exists in the module
  |
4 |     AudioServerConfig, AudioServerInfo, BufferSizeRange, MidiServerConfig, MidiServerInfo,
  |                                         ~~~~~~~~~~~~~~~
help: a similar name exists in the module
  |
4 |     AudioServerConfig, AudioServerInfo, BufferSizeInfo, MidiServerInfo, MidiServerInfo,
  |                                                         ~~~~~~~~~~~~~~

error[E0407]: method `default_midi_config` is not a member of trait `OsDevicesInfo`
  --> src\windows\mod.rs:78:5
   |
78 |       fn default_midi_config(&self) -> String {
   |       ^  ------------------- help: there is an associated function with a similar name: `default_midi_server`
   |  _____|
   | |
79 | |         if self.midi_servers_info[0].available {
80 | |             String::from("ALSA")
81 | |         } else {
82 | |             String::from("Jack")
83 | |         }
84 | |     }
   | |_____^ not a member of trait `OsDevicesInfo`

error[E0283]: type annotations needed
   --> src\windows\mod.rs:22:5
    |
22  |     type E = E;
    |     ^^^^^^^^^^^ cannot infer type for type parameter `E`
    |
    = note: cannot satisfy `E: FatalErrorHandler`
note: required by a bound in `OsStreamHandle::E`
   --> src\lib.rs:114:13
    |
114 |     type E: FatalErrorHandler;
    |             ^^^^^^^^^^^^^^^^^ required by this bound in `OsStreamHandle::E`

error[E0053]: method `default_audio_server` has an incompatible type for trait
   --> src\windows\mod.rs:71:39
    |
71  |     fn default_audio_server(&self) -> String {
    |                                       ^^^^^^
    |                                       |
    |                                       expected `&String`, found struct `String`
    |                                       help: change the output type to match the trait: `&String`
    |
   ::: src\lib.rs:126:39
    |
126 |     fn default_audio_server(&self) -> &String;
    |                                       ------- type in trait
    |
    = note: expected fn pointer `fn(&WindowsDevicesInfo) -> &String`
               found fn pointer `fn(&WindowsDevicesInfo) -> String`

error[E0046]: not all trait items implemented, missing: `default_midi_server`
   --> src\windows\mod.rs:52:1
    |
52  | impl OsDevicesInfo for WindowsDevicesInfo {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `default_midi_server` in implementation
    |
   ::: src\lib.rs:127:5
    |
127 |     fn default_midi_server(&self) -> &String;
    |     ----------------------------------------- `default_midi_server` from trait

error[E0609]: no field `buffer_size` on type `AudioDeviceInfo`
  --> src\windows\mod.rs:94:64
   |
94 |                         &self.audio_servers_info[0].devices[0].buffer_size
   |                                                                ^^^^^^^^^^^ unknown field
   |
   = note: available fields are: `name`, `in_ports`, `out_ports`, `sample_rates`, `buffer_size_range` ... and 5 others

error[E0061]: this function takes 5 arguments but 4 arguments were supplied
   --> src\lib.rs:156:24
    |
156 |             os_handle: windows::spawn_rt_thread(
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^ expected 5 arguments
157 |                 config,
    |                 ------
158 |                 use_client_name,
    |                 ---------------
159 |                 rt_process_handler,
    |                 ------------------
160 |                 fatal_error_hanlder,
    |                 ------------------- supplied 4 arguments
    |
note: function defined here
   --> src\windows\mod.rs:123:8
    |
123 | pub fn spawn_rt_thread<P: RtProcessHandler, E>(
    |        ^^^^^^^^^^^^^^^
124 |     audio_config: &AudioServerConfig,
    |     --------------------------------
125 |     midi_config: Option<&MidiServerConfig>,
    |     --------------------------------------
126 |     use_client_name: Option<String>,
    |     -------------------------------
127 |     rt_process_handler: P,
    |     ---------------------
128 |     error_callback: E,
    |     -----------------

error[E0277]: `WindowsDevicesInfo` doesn't implement `std::fmt::Debug`
  --> src\lib.rs:73:5
   |
67 | #[derive(Debug)]
   |          ----- in this derive macro expansion
...
73 |     os_info: WindowsDevicesInfo,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ `WindowsDevicesInfo` cannot be formatted using `{:?}`
   |
   = help: the trait `std::fmt::Debug` is not implemented for `WindowsDevicesInfo`
   = note: add `#[derive(Debug)]` to `WindowsDevicesInfo` or manually `impl std::fmt::Debug for WindowsDevicesInfo`
   = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0046, E0053, E0061, E0277, E0283, E0407, E0432, E0609.
For more information about an error, try `rustc --explain E0046`.
error: could not compile `rusty-daw-io` due to 8 previous errors

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.