Serialize Stereo Frame and Channel

[sigmaSd]

Hello,

I want to send Vec<Stereo32> using wavy crate over tcp stream, so it can be played by the receiver.

I believe its not currently possible, do you plan on supporting this on the future?

[AldaronLau]

I'd imagine you'd be able to use the Audio::as_f32_slice() method along with f32::to_le_bytes() in a for loop. Note you can also easily convert a Vec<Stereo32> into an Audio<Stereo32> using Audio::with_frames().

Otherwise, if you want to use a Vec instead (which it seems like you do), then you can use <Stereo32 as Frame>::channels() and unpack it further with f32::from(channel) for each channel, then using f32::to_le_bytes() to write to the TCP stream.

Another way to do it, is making a Stereo32TcpSink abstraction that implements the Sink trait, which I think would make the cleanest code.

If you request it, for one of these approaches, I'll write a code example. So, there's actually (at least) three ways to do it, although maybe none of them are obvious.

[sigmaSd]

Is the std::process::exit in pasts::block_on really needed ?

I can imagine starting the executor in separate thread when the user uses ?startaudio and coordinate its shutdown via channels when the user uses ?stopaudio, but the std::process:exit makes using the executor a one way road.

[AldaronLau]

With the way pasts currently works, not having std::process::exit() leads to undefined behavior. The reason for this is because pasts is the only executor I know of that doesn't rely on reference counting. The problem is that once a Waker is created and the executor finishes, calling wake() would result in undefined behavior, so pasts exits the program before invalidating the Waker.

I think it would be nice if pasts played nicely with the message-io crate, though, so I might look into it further.

[AldaronLau]

I should note also that you can use any executor with wavy (doesn't have to be pasts), which might be what you want to do in this situation.

[sigmaSd]

Yes using another async executor for now might solve this.

Just one more qusetion, using wavy crate I get a lot of warnings while recording/playing, example:

PipeWire ALSA [termchat]-17) client missed 1 wakeups
W][000052692.153804][impl-node.c:1040 node_on_fd_events()] (PipeWire ALSA [termchat]-17) client missed 1 wakeups
[W][000052693.115454][impl-node.c:1040 node_on_fd_events()] (PipeWire ALSA [termchat]-17) client missed 1 wakeups
[W][000052693.119488][impl-node.c:1040 node_on_f

This is obviously not ok with a tui application, is there a way to hide these warnings?

[AldaronLau]

Given that I run PulseAudio instead of PipWire for testing, this is the first I've seen of this. I don't really know anything about PipeWire (actually this is the first time I've heard of it), which is the software creating these warnings, so I'd look into PipeWire docs to find a way to hide it. I'm not sure if maybe Wavy is doing something wrong that PipeWire doesn't like, causing these warnings? If so, it could be fixed on the Wavy end of things.