Hello Gullik,
Good work - it is useful to know that we also need to sample microphone
and speaker audio at 48 kHz instead of 8 kHz. Yes sox is a good way to
do this on the command line, as it can be piped with all the other codec
2 and fdmdv programs.
BTW I have used MCUs for telephone audio in the past and they work OK -
see my $10 ATA project blog posts (e.g. from early 2011).
OK so you were testing speech samples at 10-12 bits in your earlier post
I had assumed it was the fdmdv modem samples.
A slightly better way than masking is to round the number up or down.
This can be done by adding half of a 10 bit LSB before masking.
For example, to convert a 16 bit fixed point number (1 sign bit, 15
magnitude bits) to a 10 bit sample (1 sign bit, 9 magnitude bits) you
would do:
sam_10bits = (sam_16bits) >> 6 + 0.5
which using all integer maths is:
sam_10bits = (sam_16bits + (1<<5)) >> 6
Cheers,
David
On Mon, 2012-05-28 at 21:54 +0200, Gullik Webjörn wrote:
> Hi folks,
>
> After experimenting with codec2 / fdmdv I realised that typical PC
> sound hardware is not FUN. I had a hard time finding a suitable
> soundcard / microphone combination that would yield a reasonable
> audio input for experimentation. I found that sampling the mic at 48ks
> and then downsampling with sox to 8ks yielded a much improved result.
> With this procedure I managed to produce something that after passing
> through the c2enc-mod-demod-c2dec chain was usable.
>
> (those of you with better audio h/w might disagree :-)
>
> Noting that the initial sample rate should preferably be higher, I
> started thinking about how input sample resolution would affect the
> audio, and with an idea of using a MCU for transceiver interface, I
> decided to try codec2 out with 12 and 10 bit resolution. Not to
> interfere with the codec2 hacking, I wrote a small program that read
> in the raw input file for codec2, and masked it, removing the 4 or 6
> least significant bits.
>
> Listening to the result, I could hear very little difference with a
> well adjusted audio file, (thanx peter).
>
> Next step was to pass the result through the codec2 chain, and the
> result is to my judgment very interesting, in that there is very little
> difference in the final recovered audio file.
>
> So, what do you think, this experiment is reproducible with only
> a small filter program, and maybe says something about possible future
> implementations.
>
> Regards,
>
> Gullik /SM6FBD
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
