LINUX.ORG.RU

Сообщения Putnik

 

QAudioOutput и паузы при воспроизведении

Доброго дня! Есть задача получения блоков аудиоданных из стороннего приложения (например, RTP-пакеты по UDP, фрагменты raw-файлов) и выдача после необходимых преобразований на аудио-выход в реальном времени. Всё это часть приложения, написанного на Qt, поэтому данный функционал тоже решил написать с помощью Qt (ver 5.7.0). Столкнулся с тем, что воспроизведение идет с паузами переходе одного блока QBuffer к другому. Пробовал предварительное накопление N блоков в очереди, циклический буфер, даже просто считывание файла блоками в while. Создалось впечатление, что QAudioOutput заточен под проигрывание только «завершенного» монолитного блока данных, без подбрасывания дровишек в реалтайме. В интернетах кто-то тоже не смог решить эту проблему, у кого-то якобы получалось. Если есть примеры успешного использования QAudioOutput в подобных задачах, прошу направить на путь истинный).

 ,

Putnik
()

Функция-шаблон С++ в статической библиотеке?

Пишу под Debian, набросал библиотечку с набором функций. По ходу дела понадобилось в некоторых функциях работать с различными типами данных, описал как шаблоны. Теперь undefined reference при сборке проекта, который эту библиотеку подключает и вызывает функции-шаблоны. Можно ли это обойти? Или шаблоны только в рамках одного проекта могут быть используемы?

 ,

Putnik
()

Зависает скрипт на удалении симлинка

Приветствую! Моя программа вызывает скрипт nfs_client.sh

#!/bin/sh

rm /media/config/link1
rm /media/config/link2
rm /media/config/link3

ln -fs /media/bank1/config /media/config/link1
ln -fs /media/bank2/config /media/config/link2

................
................

# Apply settings
umount -a -t nfs
mount -a

Работаю в Debian 4.14.В целом всё исправно работает, но изредка возникает ситуация, когда ПО зависает на старте. Список процессов при этом:

 2197 root       0:04 /media/bank1/software/modules/my_prog -r 0
 2260 root       0:00 {nfs_client.sh} /bin/sh /media/bank1/service_settings/nfs_client.sh
 2261 root       0:00 {dns.sh} /bin/sh /media/bank2/service_settings/dns.sh
 2266 root       0:00 rm /media/config/link3

Т.е. висим на удалении link3, соответственно, ссылки не создаются и дальнейшая корректная работа ПО затруднена. Может, кто сталкивался с чем-то подобным?

 ,

Putnik
()

ddclient и обратная зона DNS

Приветствую! Разворачиваю DNS-службу, в качестве сервера - bind9, на клиенте - ddclient. Файл ddclient.conf такой:

# /etc/ddclient/ddclient.conf
#

protocol=nsupdate
#use=if,if=
use=ip,ip=172.20.30.16
server=sur500.kuz.pul
login=/usr/bin/nsupdate
password=/etc/ddclient/Kkuz.pul.+157+38452.key
zone=kuz.pul
ttl=100
v13.kuz.pul

При запуске ddclient на сервере обновляется файл прямой зоны, корректируется А-запись для указанного хоста, всё ОК. А вот бы для него ещё в файле обратной зоны соответствующую PTR-запись обновить... В документации и тырнетах не смог найти такой опции у ddclient. Понятно, что можно вручную через nsupdate, но...

 , ,

Putnik
()

nsupdate без BIND9

Приветствую! Есть локальная сеть из нескольких десятков машин с Debian. Несколько довольно мощных, остальные весьма ограничены ресурсами и заточены под определенные задачи. Необходимо развернуть DNS-службу в сети, предусмотрев возможность как статической, так и динамической адресации машин. На мощной машине установлен bind9. На слабеньких bind9 разворачивать жирно будет, решил установить ddclient. Он поддерживает протокол nsupdate (rfc 2136). Файл ddclient.conf имеет вид (по образцу https://sourceforge.net/p/ddclient/wiki/protocols/#nsupdate):

# /etc/ddclient/ddclient.conf
#

protocol=nsupdate
#use=if,if=
use=ip,ip=172.20.30.15
server=rsv500.kuz.pul
login=/usr/bin/nsupdate
password=/etc/ddclient/Kkuz.pul.+157+38452.key
zone=kuz.pul
ttl=100
v13.kuz.pul

Т.е. ddclient использует утилиту nsupdate из состава bind9. Вопрос - можно ли её поставить без bind'a? В интернетах пишут, что dnsutils вроде бы ставится отдельно, но как-то неконкретно, не нашел четкого ответа

 ,

Putnik
()

Debian, гаснет экран после 10 минут бездействия

Приветствую!

Не могу разобраться с настройками монитора в Debian (ядро Linux 3.2.0-27-generic x86_64 GNU/Linux). Изначально при бездействии более 10 минут запускался скринсейвер, после чего форма для ввода пароля. Пошарил в настройках, сделал доступ без ввода пароля, в темах рабочего стола убрал заставку. В параметрах электропитания отменил включение режима экономии энергии.

Теперь через 10 минут экран отключается, и включается по щелчку мыши или нажатию клавиши.

Залез в etc/default/acpi_support, закомментировал интересующие параметры, не помогло. Раскомментировал, выставил их в false - тоже не помогло.

Стал искать подобие xorg.conf, забрался в usr/share/xorg.conf.d, но в имеющихся файлах не нашел ничего, напоминающего Section Screen или чего-нибудь в духе Standby mode и т.п.

В общем, не догоняю debian'овские настройки я, буду признателен за подсказки)

 , ,

Putnik
()

Падает консольное Qt-приложение, неясности с core-файлами

Приветствую! Столкнулся с периодическими вылетами проги, выполняющей прием данных с RS-232, их обработку, и выдачу пользовательских данных через RS-232 в два канала («передатчика»). Вылет может произойти и через 5 минут, и через пару часов.

Версия ОС:

Linux B7v5 3.2.0-27-generic #43astra9 SMP Fri Nov 2 01:34:28 MSK 2012 x86_64 GNU/Linux

Вкратце прога:

int main(int argc, char *argv[])
{
     QCoreApplication a(argc, argv);

    R913V Apd_r913v;

    //threads
    PRD Prd1(1,&Apd_r913v);
    PRD Prd2(2,&Apd_r913v);
    ReadFromRS232 ReadFromCom(&Apd_r913v);

    ReadFromCom.start();
    Prd1.start();
    Prd2.start();

    return a.exec();
}
class R913V : public QObject
{
   Q_OBJECT

public:
    R913V();
    ~R913V();

    ClientSocket *MS_WR_REG;     

    QMutex fkMutex, prdMutex, regMutex;
    QByteArray arrayBPU;

    qint16 out_COM_port(quint8*,qint32);
    void control_BPU(quint8);
    void write_BPU(bool);

signals:
    void toPRD1();
    void toPRD2();

};

class PRD : public QThread
{
    Q_OBJECT

public:
    PRD(quint8 channelNum,R913V *r913v);
    ~PRD();
    void run();


private:
    ServerSocket *MS_prd;
    ClientSocket *MS_ready_PRD;

    quint8 chanNum;
    R913V *r913v_apd;

    MesT_DRV  DRV;
    OUT_KDGR  OutKdgr;			

    MesT_OUT_KDGR  p_KDGR[8];
    T_Mess913v Message;
    OUT_KDGR  RegOutKdgr[8];
    int result;
    quint8 out_KDG[sizeof(MesT_OUT_KDGR)*8];
    T_OUT_KDGR_MESSAGE out_kdgr_message;

    QByteArray bytesForTrm;


    void readyPRD();

public slots:
    void sendDrv();

};

PRD::PRD(quint8 channelNum,R913V *r913v):chanNum(channelNum),r913v_apd(r913v)
{

    switch (chanNum)
    {
      case 1:
        MS_prd = new ServerSocket("MS_RS_OUT22");
        MS_ready_PRD = new ClientSocket("MS_RS_DRV22",".");
        connect(r913v_apd, SIGNAL(toPRD1()), this, SLOT(sendDrv()));
      break;

      case 2:
        MS_prd = new ServerSocket("MS_RS_OUT23");
        MS_ready_PRD = new ClientSocket("MS_RS_DRV23",".");
        connect(r913v_apd, SIGNAL(toPRD2()), this, SLOT(sendDrv()));
      break;

    }
}

void PRD::run()
{
    while(1) readyPRD();
}

//chanNum=1 для ПРД1, chanNum=2 для ПРД2
void PRD::readyPRD()
{
        memset(&out_KDG[0],0,sizeof(out_KDG));
        memset(&p_KDGR[0],0,sizeof(p_KDGR));
        memset(&Message,0,sizeof(T_Mess913v));
        bytesForTrm.clear();

        result = MS_prd->recData(&bytesForTrm);

        Q_ASSERT(bytesForTrm.size()>0 && bytesForTrm.size()<=(sizeof(MesT_OUT_KDGR)*8));

        if(bytesForTrm.size()>0 && bytesForTrm.size()<=(sizeof(MesT_OUT_KDGR)*8))
        {


     for(qint32 i=0;i<bytesForTrm.size();i++) out_KDG[i] = bytesForTrm.at(i);

   //тут фрагмент с обработкой полученных данных
   //......
   //тут фрагмент с обработкой полученных данных

        quint16 rs = r913v_apd->out_COM_port(&Message.un_mes.outbuf[0],Num_bytes);

        Q_ASSERT(rs==0);

          for (quint32 i=0;i<NumKdg-1;i++)
          {
          memset(&out_kdgr_message,0,sizeof(T_OUT_KDGR_MESSAGE));

          out_kdgr_message.TypeMessage = MES_KDGR_OUT;
          out_kdgr_message.inform.DriverAndTransmitter =
                                    RegOutKdgr[i].Transmitter;
          out_kdgr_message.inform.kdgr.WorkPart = RegOutKdgr[i].Kdgr.WorkPart;
          out_kdgr_message.inform.kdgr.InfPart[0] = RegOutKdgr[i].Kdgr.InfPart[0];
          out_kdgr_message.inform.kdgr.InfPart[1] = RegOutKdgr[i].Kdgr.InfPart[1];
          out_kdgr_message.inform.kdgr.InfPart[2] = RegOutKdgr[i].Kdgr.InfPart[2];


    //здесь запись в UDP-сокет (writeData), о котором речь в core-файлах
          r913v_apd->regMutex.lock();
          r913v_apd->MS_WR_REG->writeData((char*)&out_kdgr_message,sizeof(T_OUT_KDGR_MESSAGE));
          r913v_apd->regMutex.unlock();
          }


    } //if(bytesForTrm.size()>0 && bytesForTrm.size()<=(sizeof(MesT_OUT_KDGR)*8))
}

Получаю вот такие стеки в core-файлах:

Program terminated with signal 11, Segmentation fault.
#0  0x00007f6125347106 in QUdpSocket::writeDatagram(char const*, long long, QHostAddress const&, unsigned short) ()
   from /usr/lib/qt4.8.6/lib/libQtNetwork.so.4
(gdb) bt
#0  0x00007f6125347106 in QUdpSocket::writeDatagram(char const*, long long, QHostAddress const&, unsigned short) ()
   from /usr/lib/qt4.8.6/lib/libQtNetwork.so.4
#1  0x00007f6126244117 in ClientSocket::writeData (this=0x205ba00, data=0x7f611c5b3df0 "\264\004", size=16)
    at /home/user/work/common/trunk/SRC_COMMON/projects/base/rs_udpsocket/rs_udpsocket.cpp:210
#2  0x0000000000406983 in PRD::readyPRD (this=0x7fff0ab9d3a0)
    at /home/user/work/common/trunk/SRC_BM/projects/conf/rs_r913v/r913v.cpp:1825
#3  0x0000000000405cfa in PRD::run (this=0x7fff0ab9d3a0)
    at /home/user/work/common/trunk/SRC_BM/projects/conf/rs_r913v/r913v.cpp:1581
#4  0x00007f6124e1673c in ?? () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#5  0x00007f6124b6ddb4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007f61241124fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x0000000000000000 in ?? ()
(gdb)

Program terminated with signal 11, Segmentation fault.
#0  0x00007f6e738b25c7 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f6e738b25c7 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6e738b4878 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f6e74659285 in QString::QString(int, Qt::Initialization) () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#3  0x00007f6e7474aad1 in ?? () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#4  0x00007f6e7474ae91 in ?? () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#5  0x00007f6e7465ef8d in QString::fromAscii_helper(char const*, int) () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#6  0x00007f6e7465f00e in QString::fromAscii(char const*, int) () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#7  0x00007f6e75a44ed3 in QDebug::operator<< (this=0x7f6e6bdb1cb0, t=0x7f6e75a4bdeb "Send to ")
    at /usr/lib/qt4.8.6/include/QtCore/qdebug.h:111
#8  0x00007f6e75a41ef4 in ClientSocket::writeData (this=0x2347a20, data=0x7fff8830c9ec "\264\004", size=16)
    at /home/user/work/common/trunk/SRC_COMMON/projects/base/rs_udpsocket/rs_udpsocket.cpp:208
#9  0x0000000000406940 in PRD::readyPRD (this=0x7fff8830c810)
    at /home/user/work/common/trunk/SRC_BM/projects/conf/rs_r913v/r913v.cpp:1825
#10 0x0000000000405c4a in PRD::run (this=0x7fff8830c810)
    at /home/user/work/common/trunk/SRC_BM/projects/conf/rs_r913v/r913v.cpp:1581
#11 0x00007f6e7461473c in ?? () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#12 0x00007f6e7436bdb4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#13 0x00007f6e739104fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#14 0x0000000000000000 in ?? ()
(gdb)

Верхушка стека разнится, хотя ситуация возникает в потоке PRD, в функции writeData (написана на базе QUdpSocket, используется всеми разработчиками, у всех всё ОК). Прогонял свою прогу через valgrind, исправил выданные замечания – не помогло. Выставил в отладочной версии Q_ASSERTы, ни один при вылетах не срабатывает. Выставил mutex`ы на ресурсы, используемые в разных потоках. Просто наблюдал использование памяти в менеджере процессов – данные неизменны на протяжении всего выполнения программы. Исключил writeData из потока PRD – получил такой стек в core:

Program terminated with signal 11, Segmentation fault.
#0  0x00007f839a9a305d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/lib/qt4.8.6/lib/libQtCore.so.4
(gdb) bt
#0  0x00007f839a9a305d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#1  0x00007f839a9cda13 in ?? () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#2  0x00007f83980a1205 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f83980a1538 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007f83980a15f4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f839a9cdbc6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#6  0x00007f839a99e23f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#7  0x00007f839a99e4c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#8  0x00007f839a9a33a8 in QCoreApplication::exec() () from /usr/lib/qt4.8.6/lib/libQtCore.so.4
#9  0x0000000000406a9a in main (argc=2, argv=0x7fff93dfb418)
    at /home/user/work/common/trunk/SRC_BM/projects/conf/rs_r913v/r913v.cpp:1872
(gdb)

Думается, что в какой-то момент происходит выход за пределы массива, но не догоняю, где..(((

 , , ,

Putnik
()

Старая песня с valgrind

Доброго времени суток! Решил было потестить прогу с помощью valgrind, версия Линуха 3.2.0 -27 – generic gcc version 4.7.1 (Debian 4.7.1-2). При запуске получил следующее:

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.
В интернете довольно много всего по теме, но, как я понимаю, решения разнятся для той или иной сборки. Преимущественно предлагалось править флаги в make.conf и/или пересобирать libc6-dbg под x86. Кто-то писал, что в Debian вообще ничего с этим поделать нельзя. С этой системой работаю недавно, поэтому в системных настройках не силён... Тот же make.conf обнаружить мне не удалось. Если кто сталкивался с этим и разобрался, буду признателен за подсказки.

 ,

Putnik
()

Потеря байт при обмене по rs-232

Всем привет! Собственно, задачка с прежними условиями (ком-порт 8N1, без контроля четности, 115200 бод). Железка обменивается данными с ПК. Смотрим картинку обмена на логическом анализаторе. Данные выдаю кодограммами из 12 байт ( write (fd, buf,12) ). Иногда возникает ситуация, что при выдаче от ПК кодограмма из нескольких байт разрывается на части, интервалы между частями кодограммы варьируются от 100 мкс до 1,5 мс (на картинке эти разрывы показаны красными стрелками). Сигнал RTS при этом живет своей жизнью и сбрасывается значительно раньше (сброс RTS показан синей стрелкой). C чем такое может быть связано? Или такие разрывы правомерны в работе порта? [IMG]http://s019.radikal.ru/i640/1403/b4/801bfa6d497ct.jpg[/IMG]

Код записи в порт:

	ioctl ( fd, TIOCMGET, &status ); 
	status = TIOCM_RTS;
	ioctl ( fd, TIOCMBIS, &status );
	ioctl ( fd, TIOCMGET, &status );
	
	while ( !(status&TIOCM_CTS) && (cntWr < 10) )
	{
		cntWr++;
		status = TIOCM_RTS;
		ioctl ( fd, TIOCMBIS, &status );
 		ioctl ( fd, TIOCMGET, &status );
	}
	if ( !(status&TIOCM_CTS) ) return 1;
	

	write ( fd, buf, len );


	do       
    {
    	ioctl ( fd, TIOCSERGETLSR, &status );
    } while ( !(status & TIOCSER_TEMT) ); 

	status |= TIOCM_RTS;
	ioctl ( fd, TIOCMBIC, &status );

 ,

Putnik
()

Драйвер PCI на платформе MIPS

Здравствуйте! Нужен совет) Пишу драйвер под Linux (точнее, под отечественную линуксоподобную поделку МСВС) для платы, подключенной к PCI-Compact. Из конфигурационного пространства получаю базовые адреса, отведенные системой для взаимодействия с этой платой. На платформе Intel: в драйвере преобразовываю полученные адреса (точнее, BAR2 согласно протоколу на плату) с помощью ioremap(), и затем оперирую с преобразованным адресом и смещениями при обмене данными (writel/readl для обмена 32-битным словом, и memcpy_toio/memcpy_from_io для обмена несколькими 32-битными словами). Взаимодействие между пользовательским приложением и драйвером – посредством put_user/get_user. Всё работает отлично, плата получает все данные, реагирует согласно протоколу.

Теперь возникла необходимость адаптировать этот же драйвер под MIPS-платформу (RM7000A). Из конфигурационного пространства: BAR2=0x20500000. Ioremap() не прокатывает. Прочёл про «прямой доступ к памяти» - обращения типа writel(0x20500000, (unsigned int) data) тоже не прокатывают (“unable to page request…”). Поигрался с функцией phys_to_virt() – вроде бы всё красиво получается, данные в преобразованный адрес вроде пишутся, и потом оттуда же считываются. Но… плата молчит))) В общем, вероятно, я неверно преобразовываю исходный адрес BAR2. Не могу понять механизм преобразования адресов в MIPS((( Из руководства к RM7000A:

Figure 6 Kernel Mode Virtual Addressing (32-bit) 0xFFFFFFFF Kernel virtual address space (kseg3) 0xE0000000 Mapped, 0.5GB

0xDFFFFFFF Supervisor virtual address space (ksseg) 0xC0000000 Mapped, 0.5GB

0xBFFFFFFF Uncached kernel physical address space (kseg1) 0xA0000000 Unmapped, 0.5GB

0x9FFFFFFF Cached kernel physical address space (kseg0) 0x80000000 Unmapped, 0.5GB

0x7FFFFFFF User virtual address space (kuseg) Mapped, 2.0GB

Что-то я откровенно запутался во всяческих типах адресов)) 0х20500000 – это виртуальный, физический, или…??? Прошу помощи, если кто работал с этим.

Putnik
()

RSS подписка на новые темы