The development of the schematics for the OggStreamer are almost finished. If you want to take a look at it you can find it here:
-
Recent Posts
Archives
- September 2015
- November 2014
- April 2014
- February 2014
- November 2013
- October 2013
- September 2013
- June 2013
- May 2013
- April 2013
- February 2013
- November 2012
- October 2012
- September 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
Categories
Meta
Hey, excellent project! When we can see a PCB? As I see You use VS1063 instead VS1053?
Hi Jane,
yes we are using VS1063 – we started with the VS0153 but now switched to VS1063, mainly because this chip allows us to do monitoring, while recording.
PCBs are on their way, we are about to finish them this week.
VS1063 support encoding PCM, MP3, maybe it will be good to include this streaming format option? Ogg is (for me) too exotic… π
You forecast IceCast Server (in XportPro module), is it necessary to connect point to point (One OggStreamer to another)?
What max. bitrates Oggstreamer allow to use? 130kBps (average)?
BTW. I design my own schematic and PCB with more professional audio path (balanced in/out, direct hardware monitoring etc.) based on part of Your project.
BTW2. Sorry for my English, I hope my comments are readable… π
Hi Jan thanks for your comment.
The VS1063 supports encoding of PCM, MP3 – The design of the oggstreamer currently limits the speed between the XPortPro and STM8 to 230kBaud – so this reflects the maximum bitrate we can feed into the XPortPro – with carefull tuning this (maybe) can be increased to 920kBaud – thats more than enough for compressed audio, but not enough for raw PCM audio …
So if someone wants to write software to support MP3 – i think this is possible – but for my part i will focus on Ogg/Vorbis.
Balanced In/Out – great Idea we thought about it but we decided against it, because the OggStreamer is usually directly connected to a mixing desk – so the (unbalanced) cables can be kept very short. And we wanted to not overcomplicate our design. (at least for the first revision)
But balanced Inputs are a great Idea. *thumbsup*
Also Hardware Monitoring is great.
Hello, Great project!! Is it possible to switck the ffmp3 to the incoming stream so you can listen to the “on-air” of the studio and also use it for talk back.
FYI on DIY i was looking for the same project see: http://www.diyaudio.com/forums/pc-based/196769-stl-udp-hardware-internet-link.html
Hello Han,
thanks for you posting.
i must admit that i don’t fully understand your question. But i want to note a few things.
The OggStreamers Hardware will allow Encoding and Decoding (but not at the same time – so it is a Halfduplex-Design). And besides that it allows monitoring of the incoming signal via headphone/linout.
In the case of encoding the incoming Signal is streamed either to an external IceCast2-Server or to the internal IceCast2-Server (maybe both at the same time as well, we will see) – On the Oggstreamer there will be a light-weight webserver running and the users can start listening to the internal Stream by starting ffmp3.
I don’t know if this answers your questions but if there are questions left, feel free to post them here.
You did answer my question by telling that the system is half duplex, in my case I will use it full duplex so I can listen to the sound of the incoming stream simultaneously. So the transmit audio signal is a stereo reporter link from location to studio and the received audio is a stereo link from the studio to the location which also can be used by the engineer in the studio to talk back with the reporter on location. And that’s why it should be full duplex.