Closed DurandA closed 11 months ago
Additionally, I can extend the documentation with an example on how to read stream settings (sample rate, bit depth...) before listening in another component.
Providing a single subscription stream and not a broadcast stream was on purpose. This plays around the start/stop mechanism of the audio recorder being controlled through stream subscription. You can always turn the returned stream into a broadcast stream afterwards.
That said, what is the reason you want to turn it into a broadcast stream? The issue #69 should be resolved with 0.7.1
.
You can always turn the returned stream into a broadcast stream afterwards.
You are right, the stream can be turned into a broadcast steam afterwards which works as expected. I believe it did not behave correctly when turned into a broadcast stream in a previous version which is why I made this PR in the first place. Thank you for the feedback, I am closing this.
The issue https://github.com/anarchuser/mic_stream/issues/69 should be resolved with 0.7.1.
From what I understand, there is no 100% guarantee that the configured sample rate will be accepted. This is especially the case on iOS, as APIs almost always provide the native sampling rate and resampling is then required to achieve the desired rate. I am pushing the WAV stream to a speech-to-text service which accepts arbitrary sampling rates as long as it is negotiated/specified in advance.
Thank you for all your work on this library.
The microphone is naturally a broadcast stream. However, the public stream is a sequence of
permissionStatus
and_microphone
events usingasyncExpand
.asyncExpand
has a peculiar behavior:Before this PR, the returned stream is single-subscription even if
_microphone
is a broadcast stream. The problem with a single-subscription stream with the new (>0.7.0
) mic_stream API is described in #69.