2008/3/9, Albert Santoni <[EMAIL PROTECTED]>:
>
> Hi Wesley,
>
> When we use libshout in non-blocking mode, it means libshout is creating
> an extra thread that's taking care of buffering the compressed audio and
> sending it to the server.
>
> What I think you want to do is create a class (we'll call it Shoutcaster
> for now), that mimics the behaviour of libshout. The Shoutcaster class
> should have a member function called "send" that submits compressed
> audio to the class, which buffers it until it has the required amount of
> data to send. The Shoutcaster class should subclass QThread, and it's
> main processing function (run() in QT land) should sleep (using a
> QWaitCondition) until the required number of samples have been submitted
> to it/buffered.
When it's buffer is full, it should send it via a TCP socket to the
> Shoutcast server. After that, it should loop back and wait on the
> QWaitCondition until the buffer has been filled again.
I don't think that would work. The QTcpSocket needs an event loop.
And while it is possible to implement an event loop in a seperate thread,
it won't work if you block the thread with a QWaitCondition instead of using
an event loop (unless I'm wrong here).
>From the Qt docs: "An event loop in a thread makes it possible for the
thread to use certain non-GUI Qt classes that require the presence of an
event loop (such as QTimer <http://doc.trolltech.com/4.3/qtimer.html>,
QTcpSocket <http://doc.trolltech.com/4.3/qtcpsocket.html>, and
QProcess<http://doc.trolltech.com/4.3/qprocess.html>).
It also makes it possible to connect signals from any threads to slots of a
specific thread."
http://doc.trolltech.com/4.3/threads.html#per-thread-event-loop
Lastly, in case this wasn't clear, you should do whatever you need to do
> to set up an event loop in the Shoutcaster thread. I think that should
> fix your problem. You'll find that threading is involved with a lot of
> socket programming, especially if you want to do non-blocking stuff.
Yes, an event loop. But I can't have an event loop AND work with a
QWaitCondition (or can I?)
Should I try to do the sending over TCP in the main thread instead?
Or don't use a QWaitCondition for this extra thread and do something else
instead?
Hope this helps, and feel free ask for clarification. If anyone sees any
> obvious holes in my design, feel free to make them known. :)
>
--
Wesley Stessens <[EMAIL PROTECTED]>
Human Knowledge Belongs To The World - Antitrust (2001)
http://wesley.debianbox.be
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel