Непрерывный вывод потокового звука

[toto]

Доброго времени суток :)

Столкнулся с проблемой непрерывного вывода звукового потока.

Суть задачи проста:
по сети (TCP/IP) с устройства получаю звуковой поток на частоте дискретизации 24кГц. Поток разбит на пакеты по 512 отсчетов, я собираю свой пакет длиной 4096 отсчетов и посылаю его в очередь на воспроизведение. В отдельном цикле (надеюсь вложение вставиться :) ) из очереди извлекается мой пакет и отправляется на Sound output write.vi.
Инициализация сделана в режиме Continuous Samples, Timeout вывода стоит 0, буфер задан 4096.

Проблема: Очерель копится, при чем я делаю не поэлементное извлечение из очереди, а сразу всех пакетов которые там накопились, сшиваю пакеты и кидаю на вывод, все равно не помогает.

Вопрос: Как правильно реализовать вывод непрерывного потока звука?

PS непрерывность у меня соблюдается, я по этому звуку потом произвожу прием цифрового радиовещания, декодирование цифровых видов сигналов, если бы там были "щелчки" разрывы или потери пакетов, то это было бы не возможно, но звук накапливается, при чем еще одна важная деталь, в начале работы при считывании размер очереди чередуется 0-1-0-1-0-1, то есть она успевает вычищаться, но как только я главное окно VI сворачиваю ири разворачиваю, тут же в очереди накапливается 2-4 пакета...

[Pavel]

Доброго времени суток :)

Столкнулся с проблемой непрерывного вывода звукового потока.

Суть задачи проста:
по сети (TCP/IP) с устройства получаю звуковой поток на частоте дискретизации 24кГц. Поток разбит на пакеты по 512 отсчетов, я собираю свой пакет длиной 4096 отсчетов и посылаю его в очередь на воспроизведение. В отдельном цикле (надеюсь вложение вставиться :) ) из очереди извлекается мой пакет и отправляется на Sound output write.vi.
Инициализация сделана в режиме Continuous Samples, Timeout вывода стоит 0, буфер задан 4096.

Насколько я помню очередь не любит в большом количестве сложных типов данных. При их использовании происходит затык либо при записи либо при чтении. Попробуй передать просто массив Y.
PS: Почему бы тебе сразу полученные данные не вывести на Sound output write.vi? Зачем тебе очередь?

[mzu2006]

Очередь к сожалению штука медленная из-за шного memory manager. Когда ты задаёшь количество элементов в очереди, то это не значит что память под них выделяется сразу-же (кроме модуля real-time). Нужно сперва записать в неё все эти элементы, потом удалить - тогда выделенная паимять останется. + древовидность шных структур данных. Из-за этого мне пришлось как-то раз писать очередь самому на C++ и пристыковывать к .

[Pavel]

В Labview беда такая не только с очередями но и с событиями. Поэтому в своих проектах стараюсь оперировать “простыми” типами данных и большой объем информации не прокачивать через очереди а обрабатывать по месту. LV memory manager – это вообще отдельная песня. Если он выделяет память то это как правило навсегда хотя начиная с восьмерки появилась функция Request Deallocation котороя иногда помогает.

[mzu2006]

В Labview беда такая не только с очередями но и с событиями.

Можно поподробнее? Что именно не выделяется при инициализации? И какие события ты имеешь в виду: User Events, Visa Events ?

Если он выделяет память то это как правило навсегда

Он не отдаёт его ОС, но внутри себя-то он её перераспределяет эффективно. Или ты что-то другое имел в виду?

[Pavel]

Можно поподробнее? Что именно не выделяется при инициализации? И какие события ты имеешь в виду: User Events, Visa Events ?

Речь шла про user events. Если через событие проталкивать много данных и слишком часто то система подвиснет до тех пор пока очередь событий не опустеет.
[

Он не отдаёт его ОС, но внутри себя-то он её перераспределяет эффективно. Или ты что-то другое имел в виду?

Может быть в последних версиях LV эффективность memory manager повысилась (если можно то кинь ссылку). Но ведь отдать системе неиспользуемую память это то же своего рода эффективность.

[toto]

Чего-то вы не о том совсем, спорить не буду, но мой проект целиком построен на User Events множество модулей общаются друг с другом посредством этого мезханизма и передают сложные структуры данных, так вот никакого затыка не происходит, нужно просто оценивать объемм потока данных по этим событиям и скорость их обработки и если скорости обработки не хватает предпринимать соответствующие действия. У меня ув проекте весьма эффективно успевают передаваться обрабатываться потоки с АЦП+ со звуковой карты, + с цифровых приемников выдающих информацию в полосе 29 МГц с расфильтровкой по 1 кГц в 8ми канальном варианте. Такой поток приемник выдает до 10 раз в секунду.

[Pavel]

Меряться я надеюсь не будем у кого и сколько, понятное дело что к задаче надо подходить с умом!

[mzu2006]

как только я главное окно VI сворачиваю ири разворачиваю, тут же в очереди накапливается 2-4 пакета...

Попробуй отделить пользовательский интерфейс от обработки, может быть в этом дело. Вынеси цикл в котором крутится приём сообщений из очереди в отдельный subvi,
убери из цикла чтение всяких элементов с передней панели, перемени этой subVI систему выполнения (наппример на other1) и задай приоритет повыше. Расскажи, как получилось.


Измерить скорость я думаю придётся. Я говорил о достижении скоростей ~60MB/S пакетами по ~512x512x16bit = 512kB на машине с шиной PCI(133MB/S = 60*2 - туда и обратно)

объемм потока данных по этим событиям и скорость их обработки и если скорости обработки не хватает предпринимать соответствующие действия.

К сожалению ещё и скорость передачи играет роль.

до 10 раз в секунду

8 значений 10 раз в секунду - любая архитектура приложения должна быть способна обработать такое. Или я чего не так посчитал?

Если через событие проталкивать много данных и слишком часто то система подвиснет до тех пор пока очередь событий не опустеет.

Какие примерные объёмы и как часто? И что висит вся система при этом? Тогда действительно выделяется/освобождается память, и надо использовать очереди с предварительным выделением памяти (например тот трюк, что я говорил раньше: заполнить и освободить). Насколько мне известно с очередью пользовательских событий такого сделать нельзя.

Может быть в последних версиях LV эффективность memory manager повысилась (если можно то кинь ссылку).

Я не говорил этого. Я имел в виду, что выделение памяти операционной системой (всякие VirtualAlloc и особенно перераспределение) дело медленное, поэтому имеет свой memory manager. И с точки зрения отдавать память назад под управление ОС неэффективно.

Pavel, если хочешь обсудить особенности memory manager, я предлагаю сделать новую ветку, toto прав тут мы немного не про то начали.

[toto]

до 10 раз в секунду

8 значений 10 раз в секунду - любая архитектура приложения должна быть способна обработать такое. Или я чего не так посчитал?

Нет, примерно так (29000000/1000 * 8) и это не более 50% информации в потоке... Но думаю эту ветку можно постепенно свернуть, ясно что очереди из сложных структур медленнее чем очереди простых типов, это примерно так же как идти в гору тяжелее чем с горы, но если надо в гору, то что делать? :)