I need to resample the buffer(to (16 kHz 16-bit mono PCM) received in onDataAvaiable event of mic and speaker and then pass the stream to another application. How can this be achieved using nAudio?
Check out my article on "input driven resampling" with NAudio where I explain how you can pass the incoming audio from the soundcard to a resampler
Related
I have an external audio source that transmits audio data to my computer's sound card via S/PDIF. The sound card has an S/PDIF input. With "arecord" or "audacity" I can record over this input without any problems.
The audio source offers the data in different sample rates (32 kHz, 44.1 kHz, 48 kHz) which I cannot influence. I also can't tell from the source which sample rate the audio source has selected.
For "recording" I would now very much like to keep the sample rate and not have it converted (apparently by the sound card).
Now finally my question: Can I somehow detect with the help of Linux in which format and with which parameters the S/PDIF stream is encoded
I'm trying to use the opus Forward Error Correction (FEC) feature.
I have a service which does the encoding with OPUS_SET_INBAND_FEC(1)
and OPUS_SET_PACKET_LOSS_PERC(20) with 10ms packets and sends them over UDP.
I'm not clear on the decoding process though.
When a packet is lost, do I need to call decode with fec=1 ONLY or do I need to call decode with fec=0 after as well on the next packet?
How do I know up front the size of the pcm that I send to decode with fec enabled?
I managed to make it work.
The encoding part stated in the question was correct:
Use the encoder OPUS_SET_INBAND_FEC(1) and OPUS_SET_PACKET_LOSS_PERC(X) where x>0 ans x<100
Send packets with a duration of at least 10ms (for example: 480 samples at 48 kHz)
For the decoding part, when a packet is lost, call the decode function on the next packet first with fec=1 and again with fec=0.
When calling decode with fec=1, the pcm sent will be entirely filled.
If you don't know the length that the pcm should be use on the decoder OPUS_GET_LAST_PACKET_DURATION(x) where x will get the the duration of the last packet.
I asked earlier about H264 at RTP H.264 Packet Depacketizer
My question now is about the audio packets.
I noticed via the RTP packets that audio frames like AAC, G.711, G.726 and others all have the Marker Bit set.
I think frames are independent. am I right?
My question is: Audio is small, but I know that I can have more than one frame per RTP packet. Independent of how many frames I have, they are complete? Or it may be fragmented between RTP packets.
The difference between audio and video is that audio is typically encoded either in individual samples, or in certain [small] frames without reference to previous data. Additionally, amount of data is small. So audio does not typically need complicated fragmentation to be transmitted over RTP. However, for any payload type you should again refer to RFC that describes the details:
AAC - RTP Payload Format for MPEG-4 Audio/Visual Streams
G.711 - RTP Payload Format for ITU-T Recommendation G.711.1
G.726 - RTP Profile for Audio and Video Conferences with Minimal Control
Other
I am trying to capture the video and audio using AVCaptureSession and I done with videocapturing and converted into pixel buffer and I played the output captured video at server side using ffmpeg n rtmp server. But the thing is how can I make the audio to be converted info data and play it at sever side where the data received. And want to know what the audio format is the audio that is captured.
Thank's All,
MONISH
I have several RTP streams coming to from the network, and since RTP can only handle one stream in each direction, I need to able to merge a couple to send back to another client (could be one that is already sending an RTP stream, or not... that part isn't important).
My guess is that there is some algorithm for mixing audio bytes.
RTP Stream 1 ---------------------
\_____________________ (1 MUXED 2) RTP Stream Out
/
RTP Stream 2 ---------------------
There is an IETF draft for RTP stream Muxing which might help you the link is here http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-tanigawa-rtp-multiplex-01.txt
In case you want to use only one stream, then perhaps send data from multiple streams as different channles this link gives an overview how Audio channels are multiplexed in WAV files. You can adopt similar strategy
I think you are talking about VoIP conference.
mediastreamer2 library I think supports conference filter.