> I have lot of success to play mp3 files with library mpg123+portaudio and
> fpc unit fphttpclient.pas.
> Andrew Haines did a perfect work with his TThreadHttpGetter (that is now
> included in https://github.com/fredvs/uos).
> So getting the voice over ip is not a problem.
> For sending the voice, portaudio library and a input device is used.
> But what is the best way to finish the circle ?
> IMO, compress the microphone-wav-chunck into mp3 (with lame-mp3 encoder for
> example) and then... ?
> What fpc unit should I use to make that wav-chunck-compressed ready to use
> for TThreadHttpGetter ?
> A sample code will be very welcome.
This is not written in FPC or Delphi, but in BDS (C++) -
On 16/01/17 16:02, fredvs wrote:
> Thanks Lucaz for the link.
> But this is too complete !
> I will try to explain what i want and if it is possible to do it with
> I can successfully save to file input from mic/wav/mp3/ogg/flac to wav file.
> Is it possible that this file, while recording, could be accessible as a
> URL-file ?
I thought about it a bit... isn't this how YouTube Live Stream or Twitch and alikes somehow works?
Maybe your inspiration can come from there ?
These usually require 'special' client-side programs anyway, be it a flash-based or HTML5 video player ...
aka, not a 'normal' file-stream downloader.
> And that URL-file could be accessed by TThreadHttpGetter +fphttpclient.pas
If you can feed the HTML5 <nedia> source from fphttpclient hmm, that could be what you're after?
(provided they don't need SPDY for example, cause that's a bit different than HTTP [actually IIRC nowadays HTTP/2 it's called?])
> PS: I am not pro in web-stuffs... ;-(
Me Neither :J
> What must be done to make:
> - a url-mp3-file like 1) on server
That's just a file, you send it like a file with the proper MIME type,
is the client that reads information from the stream as needed.
> - a url-mp3-chunk like 2) on server
This is a chuncked send, you start to send information, in the header
you do not express the length, so the client will read the file up to to
the socket close (and play it).
From the send side you must write to the socket instead to a file as
you are sampling from the media input. MP3 is not a stateless
compression format, this means that each audio frame may need several
previous frames to be able to play the current one. This need is the
reason that you sometimes ears a "bleep" sound at broadcast start (non
professional). Also this dependency means that you can not compress each
source audio chunck in an mp3 and broadcast it, you must compress audio
portion in chuncks as part of a single stream.
while SocketID.Active do begin
This is a very basic guide as this code will need checks to avoid remote
contention and audiograbber overflow (usually handled by the audio
In the other side, mp3 is not a suitable format for voIP, as it have a
> This usable for uos_AddFromURL()?
I do not know, you need a chuncked send data, something that let you
send an amount of data unknown while sending, and usually you will need
at least one thread plus the main one if you need to handle more
requests at the same time.
On 17/01/17 09:04, José Mejuto wrote:
> El 16/01/2017 a las 23:10, fredvs escribió:
>> What must be done to make: - a url-mp3-file like 1) on server
> In the other side, mp3 is not a suitable format for voIP, as it have
> a big latency.
Yeah, Fred mentioned VoIP, that's why I thought of a real VoIP application to look at inspiration first..
(I happen to know...
the names or commonly used codecs for VoIP: alaw, ulaw, gsm ;) - they are apparently supported in the program I pasted a link to)
El 17/01/2017 a las 12:56, fredvs escribió:
> @ Jose => many thanks I will deeply study your advices.
>> In the other side, mp3 is not a suitable format for voIP, as it have a big
> Huh, what format would be better for voice over ip ?
G.7* (G.711 - G.7229)
And maybe some others.
> What do you think about the flac format ?
> It seams to have all the feature needed on...
> (and flac is already integrated in uos).
FLAC is basically a compressed WAV (advanced compression), so high
quality sound but low compression ratio, also it is not resilient to
dropouts, it was not designed for streaming.
If you can not find a suitable codec for your application just use a
streaming one like mp3, is not the best for the task, but can do it,
FLAC can not.
Maybe you may think in Opus http://opus-codec.org/ as it is open,
royalty free (mp3 is not free, you must pay royalties for the encoder
side) and source code is C89 so it must be compilable (libopus) in
almost any platform without a titanic effort.
Of course a RTP or alike transport is desirable, but it will introduce
much more complex tasks.
I think that if you like to continue this discussion we should move it
Yep, wrappers for libopus and libopusfile are translated and working for fpc.
Also Opus is part now of uos (and working).
Libraries for Linux64 and Win32 included (for other os, it will come asap).
Updated SimplePlayer demo with Opus sample.
El 17/01/2017 a las 16:48, José Mejuto escribió:
> Maybe you may think in Opus http://opus-codec.org/ as it is open,
> royalty free (mp3 is not free, you must pay royalties for the encoder
> side) and source code is C89 so it must be compilable (libopus) in
> almost any platform without a titanic effort.
mp3 is not free?
> El 17/01/2017 a las 16:48, José Mejuto escribió:
>> Maybe you may think in Opus http://opus-codec.org/ as it is open,
>> royalty free (mp3 is not free, you must pay royalties for the encoder
>> side) and source code is C89 so it must be compilable (libopus) in
>> almost any platform without a titanic effort.
> mp3 is not free?
> According with
> https://en.wikipedia.org/wiki/MP3#Licensing.2C_ownership_and_legislation >
> It's royalty free in European Union. And, in USA, still valid patents
> will expire along 2017. After 31 December 2017 will be completely
> royalty free in USA also.
> Don't know rest of the world. Can it be worse than in USA?
You are right, my working with MP3 technology was in 1999 so my
"standards" are very old :-)
Anyway Fraunhofer Institute which holds most known patents about MPEG
Layer III does not say "Patents expired" so maybe they can have a later
patent over technology trying to enforce it in a future and keep control
of the royalties.
Releasing a mp3 codec now could be safe in Europe (and 2018 in EEUU) but
a hardware piece could be a problem if a later patent appears in the
game. In the other hand as all known patents has expired I think no
court will be against you, maybe a "cease and desists" at most.
Anyway mp3 technology is surpassed a lot by others.
> Anyway mp3 technology is surpassed a lot by others.
Hum, first shots with Opus:
- For same quality, size of Opus is 20 % smaller than mp3.
- You may encode in different modes (voice, audio,..).
- Tag is much easier to access/edit than mp3.
- Opus: only one sample-rate: 48k (easier for mixing + DSP)
- Encoding high quality audio = +- quality of wav.
- Up to 256 channels (!)
- In same library, decoder + encoder (wow).
- Free and open source, without problems of maybe copyright expires.