On 10-Mar-08, at 10:26 AM, Wesley S. wrote: > 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, QTcpSocket, and > QProcess). 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?
Ok, so my first suggestion was going to be to create an event loop in your Shoutcaster thread using exec() and use an event to tell Shoutcaster to transmit via the QTcpSocket instead of using a QWaitCondition. However, I took a look at the Fortune example code on the QT site and it looks like you _might_ be able to do async socket stuff with just using slots and signals: http://doc.trolltech.com/4.1/network-fortuneclient-client-cpp.html You definitely don't want to transmit anything in the main thread, and you probably won't even be able to access the main thread without having to do some terrible hacks. Thoughts? Albert ------------------------------------------------------------------------- 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
