I am trying to clone the audio streaming model of QTCpsocket but now using QUdpsocket (virtual connection), though it looks like the code is being executed , nevertheless, effectively its not doing the job, I cant get streamed audio captured;
Main focus point is: is it possible to start a QAudioOutput with a QUDpsocket ???
Yet to clearly mention that this code works fine with a TCP socket!
Code snippet:
in server.h file
private:
QUdpSocket *socketUDP;
and in .CPP file
udpServer::udpServer(QObject *parent) : QObject(parent)
{
socketUDP = new QUdpSocket(this);
serverAddress = QHostAddress("192.168.1.8");
//socketUDP->bind(serverAddress, 1357);
socketUDP->bind(1357, QUdpSocket::ShareAddress);
socketUDP->open(QIODevice::ReadOnly);
connect(socketUDP, &QUdpSocket::readyRead, this, &udpServer::playStreamedAudio);
}
then the playstream() method:
void udpServer::playStreamedAudio() {
// set the QAudioFormat parameters of output audio device.
my_QAudioFormat = new QAudioFormat;
my_QAudioFormat->setSampleRate(48000);
my_QAudioFormat->setChannelCount(1);
my_QAudioFormat->setSampleSize(8);
my_QAudioFormat->setCodec("audio/pcm");
my_QAudioFormat->setByteOrder(QAudioFormat::LittleEndian);
my_QAudioFormat->setSampleType(QAudioFormat::UnSignedInt);
//
// get default audio output device
audiOutputDevice = QAudioDeviceInfo::defaultOutputDevice();
audiooutput = new QAudioOutput(audiOutputDevice,my_QAudioFormat, this);
// attach to socket!
qDebug() << "Playaing AudioStream";
socketUDP->open(QIODevice::ReadOnly);
audiooutput->start(socketUDP); // the Audio output device shall listen to server socket for audio
}
It turns out that UDP sockets may not suitability be interfaced as QioDevices... seems they are not intended to be, the packets are better be written to a file and then processed.
Related
PROBLEM DEFINITION: I have an external application called runSensor that communicates with a sensor. The sensor sends its data over UDP. Using the terminal, runSensor has two arguments to communicate with the sensor for data acquisition:start and stop.
Once at the terminal I call: $ runSensor start, a sample output is as follows:
[Time 07:20:11:000]: Device PoweredOn.
[Time 07:20:11:010]: x=1.231, y=-0.022, z=0.001
[Time 07:20:11:015]: x=1.235, y=-0.024, z=0.001
[Time 07:20:11:020]: x=1.241, y=-0.024, z=0.002
[Time 07:20:11:025]: x=1.258, y=-0.027, z=0.002
I need to call start and stop using a QT-UI. For that, I have a QDialog as follows:
Dialog::Dialog(QWidget *parent) :
QDialog(parent),
ui(new Ui::Dialog)
{
ui->setupUi(this);
this->socketHandler = std::make_shared<udpHandler>();
this->runSensorStartProcess = std::make_shared<QProcess>();
this->runSensorStopProcess = std::make_shared<QProcess> ();
//--------------------------
// SIGNAL - SLOT
//--------------------------
connect(ui->startButton, SIGNAL(clicked()), this, SLOT(onStartButtonClicked()));
connect(ui->stopButton, SIGNAL(clicked()), this, SLOT(onStopButtonClicked()));
connect(this->socketHandler.get(), SIGNAL(sendUdpContent(QString)), this, SLOT(updateMessageBrowser(QString)));
connect(this->runSensorStartProcess.get(), SIGNAL(readyReadStandardError()), this, SLOT(printError()));
}
I use QProcess to call the start and stop of runSensor application. When I push the GUI's start button, data acquisition starts, but the the GUI freezes and I cann't click on the stop button.
CODE EXTRACTS: Here is how I implemented the start button click:
void Dialog::onStartButtonClicked()
{
this->runSensorStartProcess->start("start");
//this->runSensorStartProcess->waitForFinished(-1);
//--------------------------
// udp socket handler starts picking data and write it into a file
//--------------------------
if (!this->runSensorStartProcess->waitForStarted())
{
qWarning() << "Warning: Cannot start Cygwin process!";
}
}
stop button click implementation is similar:
void Dialog::onStopButtonClicked()
{
if(this->runSensorStartProcess.get() != NULL)
{
this->runSensorStartProcess->close();
}
this->runSensorStopProcess->start("stop");
if (!this->runSensorStopProcess->waitForStarted())
{
qWarning() << "Warning: Cannot stop Cygwin!";
}
}
Question:
How can I keep th GUI responsive after runSensorStartProcess starts?
How can I stop that process on demand (in fact by starting runSensorStartProcess)?
Do I need a separate thread for runSensorStartProcess?
Don't use any of the waitForXxx methods. That's all. Yes, it's that simple.
Note that for every waitForXxx method there's a signal you can attach to and thus react to the event you're looking for.
Aren't QProcess::kill and QProcess::terminate what you need?
Never. See also answer 1 and answer 2.
actually i have Qt code. so i need to send data of packets from serial port to terminal and display the data in terminal and also from terminal i need to read data and display it in Qt window page. main problem is, for serial communication to terminal, does we really require serial port should connect to some hardware devices and also.. can we write and read data to terminal without connecting any serial port to hardware devices.
the code from Transceiver layer to serial port
Transceiver::Transceiver(QObject *parent)
:
QObject(parent),
mSerial(new QSerialPort(this))
{
mSerial->setPortName(QString("COM1"));
qint32 baudRate = 9600;
mSerial->setBaudRate(baudRate);
mSerial->setDataBits(QSerialPort::Data8);
mSerial->setParity(QSerialPort::NoParity);
mSerial->setStopBits(QSerialPort::OneStop);
connect
(
mSerial,
&QSerialPort::readyRead,
[ this ]()
{
QByteArray data = mSerial->readAll();
OnDataReceived( data );
qDebug()<<data;
}
);
}
Transceiver::~Transceiver()
{
mSerial->close();
}
void
Transceiver::Send_Data(const QByteArray & inDataStream )
{
qDebug()<<"Data_in_Transceiver_layer :"<<inDataStream;
mSerial->write(inDataStream);
}
bool
Transceiver::OpenConnection()
{
mSerial->open(QIODevice::ReadWrite);
QSerialPort::SerialPortError error = m`enter code here`Serial->error();
return error == QSerialPort::NoError;
// connect(mSerial, SIGNAL(readyRead()), this, SLOT(read_data()));
}
when i run this it shows
QIODevice::write (QSerialPort): device not open
I'm downloading files from a remote server with Qt5.5 and everything works fine but I can't detect when a QNetworkReply returns an error.
In fact, I am trying to check the case if the user is downloading a file and suddenly, he loses his Internet connection (because why not :-) ). To do that, I start a download and unplug my Ethernet cable a few seconds after.
Is the signal QNetworkReply::error(QNetworkReply::NetworkError) emitted in this case? If yes, why am I not entering my slot in my code below?
void MyClass::download(QUrl url)
{
QNetworkRequest request = QNetworkRequest(url);
QNetworkReply *reply = pManager.get(request);
// finished() is called after error(), but try both
connect(reply, SIGNAL(error(QNetworkReply::NetworkError)), this, SLOT(requestError(QNetworkReply::NetworkError)));
connect(reply, SIGNAL(finished()), this, SLOT(requestFinished()));
}
void MyClass::requestError(QNetworkReply::NetworkError err)
{
qDebug() << "error";
}
void MyClass::requestFinished()
{
qDebug() << "finished";
}
I also connected the access manager like this :
connect(&pManager, SIGNAL(finished(QNetworkReply*)), SLOT(requestFinished(QNetworkReply*)));
When the Internet connection is not interrupted, I am going in the slot requestFinished(), but if there's not Internet anymore, I am not entering any slot.
Am I doing something wrong?
Ok, nevermind, I was doing it wrong. Since I want to check the internet connection, I have to check the network availability via QNetworkAccessManager, by doing this :
QNetworkConfigurationManager manager;
pManager.setConfiguration(manager.defaultConfiguration());
connect(&pManager, SIGNAL(networkAccessibleChanged(QNetworkAccessManager::NetworkAccessibility)), this, SLOT(networkAccessibleChanged(QNetworkAccessManager::NetworkAccessibility)));
And when the Internet breaks down, I will be in the corresponding slot.
I have to develop a C++ program for an embedded FriendlyARM-based processor system.
I use Qt Creator 3.0.0 (based on Qt 5.2.0) for desktop computer. My program should be able to read from serial port at Mini2440 FriendlyARM processor.
Before going to target system (embedded system), I tried to read and write from/to a serial port on my Laptop. My main problem is how to read from serial port. As you know, new computers and laptops don't have serial port so I try to simulate serial port programming using hand-made USB-to-serial adapter cable. When the USB serial cable is plugged in, it is recognized as "/dev/ttyUSB0" on Ubuntu. It seems to work well.
Please note, the other end of cable (the serial port) isn't connected to anything.
My first question is: Is it OK to configure cable like this, or I have to connect it to other device?
I try to wrote to /dev/ttyUSB0 each 10 seconds and read the data. I ended up the following code:
void MainWindow::refreshNotificationArea()
{
generateNotifAreaData(); // a typical random data-generator
QList<QSerialPortInfo> L = QSerialPortInfo::availablePorts();
for (auto e : L)
qDebug() << e.portName() << '\n'; // it prints 1 serial port: :ttyUSB0
// write to the port
QSerialPort notifAreaPort;
// 1. set properties
notifAreaPort.setBaudRate(QSerialPort::Baud9600);
notifAreaPort.setStopBits(QSerialPort::OneStop);
notifAreaPort.setParity(QSerialPort::NoParity);
notifAreaPort.setDataBits(QSerialPort::Data8);
notifAreaPort.setFlowControl(QSerialPort::NoFlowControl);
QObject::connect(¬ifAreaPort,SIGNAL(error(QSerialPort::SerialPortError)),
this, SLOT(errorReport(QSerialPort::SerialPortError)));
notifAreaPort.setPortName(serial_device.c_str());
// 2. open port
notifAreaPort.open(QIODevice::ReadWrite);
if (!notifAreaPort.isOpen())
qDebug() << "Open failed"; // open is OK, no error message printed
string s = convertNotifAreadData2Str();
qDebug() << "Generated data " << s.c_str(); // OK
int a = notifAreaPort.write(s.c_str()); // write done
qDebug() << "Write count" << a; // OK
// now read the info
QByteArray ba = notifAreaPort.readLine(3); // read failed
QSerialPort::SerialPortError err = notifAreaPort.error();
qDebug() << "Error code" << err;
qDebug() << "What? " << notifAreaPort.errorString();
qDebug() << "Read count " << ba.size(); // 0
notifAreaPort.close();
}
void MainWindow::errorReport(QSerialPort::SerialPortError error)
{
if(error!=0)
qDebug()<<"ERROR:"<<endl<<error; // nothing printed
}
Writing to serial port is OK. but Reading issues sometimes "No such file or directory"!
sometimes "File temporarily unavalable!
The strange thing is notifAreaPort.error() returns 0, and it means no error
occured!
Thoughts?
-- Saeed Amrollahi Boyouki
You cannot (well, SHOULD not) write then read from a QSerialPort in the same function.
There are two methods which I use for QSerialPort processing:
METHOD ONE
Create and open your QSerialPort object.
Set up a QTimer with a timeout of around 50 ms or so (depends on hardware).
Connect the readyRead() signal to a slot which basically just reads all data into your buffer (QByteArray is ideal for this). The slot stops the QTimer, reads all data available with readAll() and then restarts the QTimer and returns.
Connect the timeout signal of the QTimer to a function to process the read bytes of input.
The premise here is that eventually all data will have arrived and the QTimer will timeout, at which point you will have had all of your data in the buffer to process.
METHOD TWO
The slot which handles readyRead() signal can check all data in the buffer for some "marker" which denotes that some chunk of data has fully arrived. Many devices use 0x0D or 0x0d0x0A as the delmiter. Others use NULL 0x00 or some other byte.
Evaluate the buffer at each iteration of the readyRead() handler slot.
This example shows the second choice and it works well for small reads.
r_port = new QSerialPort(this);
r_port->setPortName("COM3");
r_port->setBaudRate(QSerialPort::Baud9600);
r_port->setDataBits(QSerialPort::Data8);
r_port->setParity(QSerialPort::NoParity);
r_port->setStopBits(QSerialPort::OneStop);
r_port->setFlowControl(QSerialPort::NoFlowControl);
if (r_port->open(QSerialPort::ReadWrite))
{
connect(r_port, &QSerialPort::readyRead, this, &MYPROG::on_readyRead);
connect(r_port, &QSerialPort::errorOccurred, this, &MYPROG::breakCaught);
}
else
{
QMessageBox::critical(this, "SERIAL PORT NOT CONNECTED", "Unable to connect to the radio.\n\nPlease check your connections\nand configuration and try again.");
return;
}
void MYPROG::on_readyRead()
{
// keep reading until we get a \r\n delimiter
rxBytes.append(r_port->readAll());
qDebug()<<"raw rxBtes"<<rxBytes;
if(!rxBytes.contains("\r\n"))
{
return;
}
int end = rxBytes.lastIndexOf("\r\n") + 2;
QStringList cmds = QString(rxBytes.mid(0, end)).split("\r\n", QString::SkipEmptyParts);
rxBytes = rxBytes.mid(end);
foreach(QString cmd, cmds){
qDebug()<<"serial read"<<cmd;
}
}
This allows the QSerialPort to be read when data arrives and then the program can return to the event loop in order to keep a GUI from becoming unresponsive. Typical serial reads are small and of short time duration so UI freezing rarely happens using these methods.
There are a couple of issues in your code, but I will highlight the most important of those:
You are setting the parameters before opening. This should happen after opening. That is how the API was sadly designed, but we are in the process of revamping it.
You should command line examples for reading that I added in 5.2? It seems that you do not know how to read and those would give you a simple example. In short: you are basically trying to read before the write potentially even finished.
„Hand-made USB to serial adapter“ - sounds interesting. Are you sure that this works correctly?. I think it’s a good idea to connect PIN 2(Rx) and 3(Tx), so you getting data. Now you can test your device with any other terminal software.
I use for serial ports always the readyRead() signal and I check before reading with port->bytesAvailable().
And I open my port with port->open(QIODevice::ReadWrite | QIODevice::Unbuffered).
I'm developing an application that uses IPC between a local server and a client application. There is nothing particular to it, as it's structured like the Qt documentation and examples.
The problem is that the client sends packets frequently and connecting/disconnecting from the server local socket (named pipe on NT) is very slow. So what I'm trying to achieve is a "persistent" connection between the two applications.
The client application connects to the local server (QLocalServer) without any problem:
void IRtsClientImpl::ConnectToServer(const QString& name)
{
connect(_socket, SIGNAL(connected()), this, SIGNAL(connected()));
_blockSize = 0;
_socket->abort();
_socket->connectToServer(name, QIODevice::ReadWrite);
}
And sends requests also in the traditional Qt manner:
void IRtsClientImpl::SendRequest( quint8 cmd, const QVariant* const param_array,
unsigned int cParams )
{
// Send data through socket
QByteArray hdr(PROTO_BLK_HEADER_PROJ);
QByteArray dataBlock;
QDataStream out(&dataBlock, QIODevice::WriteOnly);
out.setVersion(QDataStream::Qt_4_5);
quint8 command = cmd;
out << blocksize_t(0) // block size
<< hdr // header
<< quint32(PROTO_VERSION_PROJ) // protocol version
<< command // command
<< cParams; // number of valid parameters
for (unsigned int i = 0; i < cParams; ++i)
out << param_array[i];
// Write the current block size
out.device()->seek(0);
out << dataBlock.size() - sizeof(blocksize_t);
_socket->write(dataBlock);
}
No problem. But the trick resides on the readyRead() signal in the server-side. Here's the current implementation of the readyRead() handling slot:
void IRtsServerImpl::onReadyRead()
{
QDataStream in(_lsock);
in.setVersion(QDataStream::Qt_4_5);
if (_blocksize == 0)
{
qDebug("Bytes Available on socket: %d", _lsock->bytesAvailable());
if (_lsock->bytesAvailable() < sizeof(blocksize_t))
return;
in >> _blocksize;
}
// We need more data?
if (_lsock->bytesAvailable() < _blocksize)
return;
ReadRequest(in);
// Reset
_blocksize = 0;
}
Without setting _blocksize to zero I could not receive more data, only the first block group (I would expect an entire block to arrive without segmentation since this is through a pipe, but it does not, go figure). I expect that behavior, sure, since the _blocksize does not represent the current stream flow anymore. All right, resetting _blocksize does the trick, but I can't resend another packet from the client without getting an increasing array of bytes on the socket. What I want is to process the request in ReadRequest and receive the next data blocks without resorting to connecting/reconnecting the applications involved.
Maybe I should 'regulate' the rate of the incoming data?
Thank you very much.