sending audio

[josh--]

first off, this is awesome i figured i was going to end up having to put something like this together myself but it's already done!

on that note; has anyone had any luck sending audio to their cam? this utility appears to send the audio to the cam just fine. However it always sounds completely messed up when outputting through the cam. Initially i started with just curl with the same result until i stumbled upon this.

im assuming it's some type of audio encoding issue. I have tried sending in most of the available formats with different bit/sample rates with no luck.

so far this encoding gets me the closest but it's still FAR from correct

G.711A as content type
ffmpeg -i 4353.mp3 -c:a pcm_alaw -ac 1 -ar 16000 -sample_fmt s16 output.wav

[tchellomello]

Hello @josh-- ,

@dougsland do you know any particular format required on this case?

[tchellomello]

@josh-- did you try something like this?

camera.audio_stream_capture(httptype="singlepart", channel=1, path_file="/home/user/Desktop/audio.aac")
CTRL-C to stop the continuous audio flow or use a timer

[josh--]

@tchellomello do you mean using singlepart vs multipart? if so then yes.

With pretty much all the audio formats i tested, i attempted with both multi and singlepart. In testing both methods i haven't noticed a real difference in what gets output from the cam.

thanks again!

[dougsland]

Hi @josh-- @tchellomello -- yes, for me it worked fine with G.711A.

You can try:
$ amcrest-cli -H 192.168.1.10 -u admin -p password --audio-send-stream singlepart 1 /path/file.wav G.711A

where:

• singlepart is the httptype but can be multipart

  More details:
  singlepart: HTTP content is a continuos flow of audio packets
  multipart: HTTP content type is multipart/x-mixed-replace, and
  each audio packet ends with a boundary string

• 1 is the channel

According with amcrest docs, the supported codecs are:
Supported audio encode type according with documentation:
PCM
ADPCM
G.711A
G.711.Mu
G.726
G.729
MPEG2
AMR
AAC

[josh--]

@dougsland thats pretty much what i have been trying however it always comes out completely garbled on the speaker end. If i use the lame amcrest web plugin audio sounds fine.

do you perhaps have a sample wav file i could try out? or any idea what settings i would use (sox/ffmpeg) to produce the correct type of output?

sox input.mp3 -r 8k -c 1 -e a-law sox-alaw.wav

that sort of works, but the camera output is weird. it starts up alright then it seems like it rapidly speed up and be to the point where it is inaudible.

[josh--]

so i think i finally have this squared away unfortunately it doesn't work utilizing this script

using the following i was able to encode to the correct G.711A codec (this was working all along)

sox -v 0.8 input.mp3 -r 8k -c 1 sox-alaw.al

however because of the speed up i mentioned before i thought perhaps it was just sending too much at once and voila. I rate limited curl to the same rate as audio file and it plays as expected...

below is a sample of the curl call used

curl -vvv \
--limit-rate 8K \
-F "file=@sox-alaw.al;type=Audio/G.711A" \
-H "Content-Type: Audio/G.711A" \
http://user:pass@192.168.1.200/cgi-bin/audio.cgi\?action\=postAudio\&httptype\=singlepart\&channel\=1

[tchellomello]

Hello @josh--,
Thanks for providing an example . I download this audio file to test: https://www.freesound.org/people/FoolBoyMedia/sounds/352652/

Then I converted it as you showed using sox:

$ sox -v 0.8 352652__foolboymedia__piano-notification-2.mp3  -r 8k -c1 sox-piano-notification.al

Then I tried to upload it using the amcrest-cli:

amcrest-cli --camera amcrestcam1 --audio-send-stream singlepart 1 sox-piano-notification.al G.711A

Which worked great!! It reproduced the same effect as using the curl command.

Can you check with the command amcrest-cli about to see if that will work too?

[josh--]

@tchellomello can confirm that particular file works fine using the amcrest-cli as well as with curl. I think the main issue was due to the length of the track i was using. I was attempting to send 30s plus audio files. I'm assuming sending something longer at full speed overwhelms the camera.

the following track will produce the problems im running into. It works fine using the rate limited curl but sounds all jumbled after a few seconds using amcrest-cli

http://www.bensound.com/royalty-free-music?download=sunny

[tchellomello]

Closing this issue since it worked as expected :)

[josh--]

@tchellomello just wanted to point out that this still doesn't work. using the file you provided works because it less than a few seconds long. attempting to send anything else (a music track for instance) will not work correctly. I believe the camera is expecting an audio playback stream rather than a file upload.