sigmaN 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Интересно, а можно ли на целочисленном DSP с запасом производительности(скажем в 3-5 раз) зарулить вокодер на плавающей точке? И вообще, каков overhead, так сказать, FP операций на проце без FPU? Страдает ли точность вычисления? Что нужно для подобных "извращений"? Может быть есть какая-то библиотека виртуального FPU, так сказать? DSP Техас 55 серии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fontp 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Можно, только не в 3-5, а скорее раз 8-10 Для этого обычно строят библиотеки "короткого" нестандартного FP Чтобы удобно (т.е. быстро) было работать. Слово мантисы + слово экспоненты И никаких проверок на потерю точности - с ними всё равно нечего делать в риал-тайме Ещё они должны быть inline, иначе труба Такие библиотеки есть. Можете и сами написать умножение деление сложение и вычитание. Преобразование типа из/в int и float можно где-нибудь найти на С Если Вы хотите приспособить к SPEEX без переписывания, то проблемы всё равно останутся. Во-первых операторами можно оформить только в СPP, в С это функции/ SPEEX это С, а значит... Во-вторых в чужих проектах используются стандартные математические библиотеки math.h, а это уж точно прийдётся самому писать под новый тип новую реализацию - sin, sqr, и что там ещё есть в SPEEX Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Можно, только не в 3-5, а скорее раз 8-10 Да уж... труба дело :-) Неужели всё-таки придется окунуться в математику и переписывать некоторые алгоритмы на целочисленную модель. А есть где-нибудь мануальчики как это обычно делается. Ну там, начиная от анализа существующего FP алгоритма и так далее чтобы на выходе был ФТ алгоритм. Видимо от этого никуда не деться....:-( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fontp 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Да уж... труба дело :-) Неужели всё-таки придется окунуться в математику и переписывать некоторые алгоритмы на целочисленную модель. А есть где-нибудь мануальчики как это обычно делается. Ну там, начиная от анализа существующего FP алгоритма и так далее чтобы на выходе был ФТ алгоритм. Видимо от этого никуда не деться....:-( Если никуда не деться... Могу посоветовать AN EE-185 для BF Там хоть преобразование типов есть на С, операции на асемблере (делать самому, если не знать его ассемблера, чтобы использовать как прототип), ну и вообще по тексту описание FastFloat16 или FastFloat32 Это на www.analog.com Application Note Как у ti c такими библиотеками - не знаю, возможно, что и есть Математику, в смысле, стандартные функции с нужной точностью - самому Потом грамотно целый класс в С++ накропать Типа c таким прототипом http://www.koders.com/cpp/fid5E90955711BFB...C383C.aspx#L103 Потом все модули SPEEX переименовать в cpp, компилировать и править ошибки :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DRUID3 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Если никуда не деться... Могу посоветовать AN EE-185 для BF Там хоть преобразование типов есть на С, операции на асемблере (самому, если не знать его ассемблера, чтобы использовать как прототип), ну и вообще по тексту описание FastFloat16 или FastFloat32 Это на www.analog.com Application Note Как у ti c такими библиотеками - не знаю, возможно, что и есть Математику, в смысле, стандартные функции с нужной точностью - самому Потом грамотно целый класс в С++ накропать Типа c таким прототипом http://www.koders.com/cpp/fid5E90955711BFB...C383C.aspx#L103 Потом все модули SPEEX переименовать в cpp, компилировать и править ошибки :-) :07: Я еще speex не собирал, и вот заинтересовался темой. Но... во-первых - помниЦЦо в VDSP++ есть float для целочисленных процессоров. В чем проблема? На Bf все будет летать и так. Что надо переписывать? Я кода-то с float алгоритмы переносил на fix так и то вспоминать не хочу больше... а если еще самому мутить матлибу (пусть и "быстрый float")- это ошибки человека + ошибки принципиальные - ну как в fix с масштабированием. во-вторых - насколько я понимаю Linuxовый Speex для bf - целочисленный...и он вполне собираеЦЦо...??? Есть целочисленный вход/выход, в портах для TMS и BF используются типы данных на основе int. ... Что еще надо для души? Ну и в-тетьих, если так хочеЦЦо float - то у AD есть серия дешевых SHARKов, они собственно для того и создавались что-бы не ломая голову применять акадэмические(книжные) алгоритмы. Тем более что их производительности хватит еще на корзинку таких speexов... P.S.: собственно мне не понравился подход... не хочу чтобы медаппаратуру, например, даже для зубного кабинета, разрабатывали так... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fontp 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба :07: Я еще speex не собирал, и вот заинтересовался темой. Но... во-первых насколько я помню в VDSP++ есть float для целочисленных процессоров. В чем проблема? На Bf все будет летать и так. Что надо переписывать? Я кода-то с float алгоритмы переносил на fix так и то вспоминать не хочу больше...а если еще самому мутить матлибу - это ошибки человека + ошибки принципиальные - ну как в fix с масштабированием. во-вторых - насколько я понимаю Linuxовый Speex для bf - целочисленный...и он вполне собираеЦЦо...??? Есть целочисленный вход/выход, в портах для TMS и BF используются типы данных на основе int. ... Что еще надо для души? Он хочет VBR, jitter buffer и эхоподавитель А все эксперементальные, недоделаные фичи в SPEEX - float, что в общем-то правильно. Зачем вылизывать алгоритмы, которые ещё десять раз будут переделаны? Порты BF и TMS int но он их не хочет ;-) В стандартном float32 ни BF ни TMS sPEEX с прибабахами не потянут Вообще-то float всегда это больше fast prototyping - типа для лохов. Но человек хочет повозиться с прибабахами. Я так понимаю Быстродействие int на BF я проверял http://electronix.ru/forum/index.php?showt...36206&st=15 На tms помедленей, упомянуто там же Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Он хочет VBR, jitter buffer и эхоподавитель А все эксперементальные, недоделаные фичи в SPEEX - float, что в общем-то правильно. Зачем вылизывать алгоритмы, которые ещё десять раз будут переделаны? Порты BF и TMS int но он их не хочет ;-) В стандартном float32 ни BF ни TMS sPEEX с прибабахами не потянут Вообще-то float всегда это больше fast prototyping - типа для лохов. Но человек хочет повозиться с прибабахами. Я так понимаю Быстродействие int на BF я проверял http://electronix.ru/forum/index.php?showt...36206&st=15 На tms помедленей, упомянуто там же Правильно понимаете. Мне очень нужны именно эти фичи - без VBR и эхоподавления никак мне не жить. На int там действительно только кодер/декодер - этого мало для решения моей задачи. То, что типа для лохов - это тоже верно, но щас важнее чтоб по быстрому всё заработало и запахло капустой :-) Потом следующую версию забабахаю на ФТ(если получится). Есть ведь TMS320F28335 c FPU - вот на нем всё это без переделок пойдет. Просто жрет он очень много! Это меня и насторожило. То, что тема это гнилая(мутить алгоритм ПТ на процах ФТ) - и ежу понятно, хотелось просто это ещё раз услышать. :) Вообще Speex очень хорош! Я на PC провел испытания качества на низких битрейтах - просто сказка! Нужно будет взяться и разрулить как-нибудь всё на ФТ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DRUID3 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Он хочет VBR, jitter buffer и эхоподавитель А все эксперементальные, недоделаные фичи в SPEEX - float, что в общем-то правильно. Зачем вылизывать алгоритмы, которые ещё десять раз будут переделаны? Порты BF и TMS int но он их не хочет ;-) В стандартном float32 ни BF ни TMS sPEEX с прибабахами не потянут Вообще-то float всегда это больше fast prototyping - типа для лохов. Но человек хочет повозиться с прибабахами. Я так понимаю Быстродействие int на BF я проверял http://electronix.ru/forum/index.php?showt...36206&st=15 На tms помедленей, упомянуто там же Ну спасибо...так перечеркнуть все мои надежды на SHARC. К стати, они его не даром для музыки и радиолюбителей позиционируют, ибо это еще и low digital noise in superlongest accumulation operation . а так, по кодеку, вобщем ясно... Кстати, я тут недавно заинтересовался нелинейными системами, а там чем больше точность тем больше матриц матриц которые матрицы матриц ...может попробую bf561 тем более и луникс для него оказываеЦЦо есть. Если правильно распределить потоки - то в среднем можно на суммарнуй 1 Гигатакт расчитывать....уж если он speex float не потянет, то даже не знаю... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stanislav 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Интересно, а можно ли на целочисленном DSP с запасом производительности(скажем в 3-5 раз) зарулить вокодер на плавающей точке?Нельзя. И вообще, каков overhead, так сказать, FP операций на проце без FPU?Примерно два порядка. Страдает ли точность вычисления?Относительно чего? Что нужно для подобных "извращений"?Быть "извращенцем". Может быть есть какая-то библиотека виртуального FPU, так сказать? DSP Техас 55 серии. Библы есть какие-то, конечно, в т.ч., и стандартные. Только зачем они Вам? Компилятор плывучку поддерживает и для целочисленных DSP, а для нормальной плавающей точки нужно брать и процессор соответствующий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба Нельзя. Примерно два порядка. Относительно чего? Быть "извращенцем". Библы есть какие-то, конечно, в т.ч., и стандартные. Только зачем они Вам? Компилятор плывучку поддерживает и для целочисленных DSP, а для нормальной плавающей точки нужно брать и процессор соответствующий. Ясно всё. В общем нужно детальнее разбираться в алгоритмах работы нужных мне фич и не обращать внимание на плывучку, как вы говорите. Точность Относительно чего? Ну я имел ввиду относительно DSP с FPU. Но, понятно, вопрос дурацкий на самом деле:) А можно какие-нибудь подсказки по методике перевода алгоритма на целочисленные вычисления? Я, честно говоря, пока четко себе не представляю сам процесс.... :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stanislav 0 3 апреля, 2008 Опубликовано 3 апреля, 2008 · Жалоба В общем нужно детальнее разбираться в алгоритмах работы нужных мне фич и не обращать внимание на плывучку, как вы говорите.Строго говоря, вычисления лучше делать не в целых числах, а в числах с фиксированной точкой (fixed point arithmetics). Попробуйте погуглить - найдёте немало интересного. Кроме того, на сайтах AD и TI есть много статей, аппнотов и мануалов, посвящённых данному вопросу. Однакож, и "плавающие" DSP никто не запретил юзать. :) Попробуйте-ка найти приличный fixed-point DSP за такую цену. ;) ...А можно какие-нибудь подсказки по методике перевода алгоритма на целочисленные вычисления? Я, честно говоря, пока четко себе не представляю сам процесс... Выше уже написал. Программирование в числах с фиксированной точкой требует большой аккуратности - постоянно приходится считаться с возможностью как переполнения, так и значительной потери точности на операциях разного рода. Это программист должен постоянно помнить, и нормировать и масштабировать не покладая рук. В целом, конечно, с приобретением должного опыта эти вещи будут получаться автоматически. Есть и хитрости более "высокого порядка". Например, во многих вокодерах для параметрического оценивания используется рекурсивный алгоритм Левинсона-Дарбина, который весьма чувствителен к усечению разрядов. Заменив его на немного менее эффективный вычислительно метод LeRoux (Schur recursion), получим гораздо большую устойчивость решения для DSP с фиксированной точкой. Кроме того, часть вычислений (не менее 10-20%) придётся писать на АСМе, потому что ЯВУ не поддерживают многие полезности архитектур DSP. ЗЫ. А вообще, посмотрите стандарты. Алгоритмы работы вокодеров создаются обычно так, чтобы их легко можно было реализовать в целочисленном процессоре. ЗЗЫ. А почему именно SPEEX? Послушал сэмплы на сайте speex.org - не понравилось мне звучание, особенно при малых битрейтах. Тот же G723.1 звучит заметно лучше, да и и MELP при 2400 бит/с ему точно не уступает... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fontp 0 4 апреля, 2008 Опубликовано 4 апреля, 2008 · Жалоба ЗЗЫ. А почему именно SPEEX? Послушал сэмплы на сайте speex.org - не понравилось мне звучание, особенно при малых битрейтах. Тот же G723.1 звучит заметно лучше, да и и MELP при 2400 бит/с ему точно не уступает... SPEEX CELP и звучит как CELP. Как G723.1 на 5.3 кб/cек. А MELP звучит конечно великолепно для 2.4кб/сек, но в целом так себе, если с потоком не париться В варианте VBR SPEEX по идее должен, как говорят авторы, звучать лучше большинства стандартных. Верю. Есть правда и стандарты VBR - тот же G726.2 AMR-NB C другой стороны переменный битовый поток порождает свои проблемы - с тем же буфером джитера и всё такое. SPEEX "просто сказка" в том смысле, что там есть много чего нахаляву. Дело не только в том, что он open source, но и в том, что там много всяких дополнительных вкусностей. На вкус и цвет..., пусть расцветают все цветы..., у SPEEX есть тоже свои достоинства Потом речь идёт не о том, чтобы "сделать", а о том, чтобы портировать готовое. Т.е. на С и если говорить о sPEEX vbr - то во float. Во float по нормальному, вообще-то лучше использовать float процессор. И действительно, стандартный IEEE float тянет примерно два порядка быстродействия на процессоре FIXED Или пользоваться суррогатными типами если нужно сделать за так и быстро :-) Тянет примерно один порядок Пацан спросил-пацан ответел :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stanislav 0 4 апреля, 2008 Опубликовано 4 апреля, 2008 · Жалоба SPEEX CELP и звучит как CELP. Как G723.1 на 6.3 кб/cек.Не знаю, может, сэмплы неудачные, но по мне, так SPEEX 6 кб/с звучит значительно хуже G 723.1 5.3 кб/с. Кроме того, G723.1 - это не CELP, которым, как известно, является FS-1016, и SPEEX очень похож на него. У G723.1 формирование адаптивной кодовой книги производится иным способом. ...А MELP звучит конечно великолепно для 2.4кб/сек, но в целом так себе, если с потоком не паритьсяМне показалось, что никак уж не хуже SPEEX на нижнем битрейте. В варианте VBR SPEEX по идее должен, как говорят авторы, звучать лучше большинства стандартных.Интересно, а за счёт чего он будет звучать лучше, скажем, того же FS-1016? Ну, а на VBR можно переделать любой вокодер. С уменьшением устойчивости к ошибкам передачи, естественно. ...C другой стороны переменный битовый поток порождает свои проблемы - с тем же буфером джитера и всё такое. SPEEX "просто сказка" в том смысле, что там есть много чего нахаляву. Дело не только в том, что он open source, но и в том, что там много всяких дополнительных вкусностей. На вкус и цвет..., пусть расцветают все цветы..., у SPEEX есть тоже свои достоинстваС этим спорить не буду. Нахаляву оно, конечно, слаще... Не подумайте, что я отношусь неодобрительно к SPEEX проекту - наоборот, считаю его очень полезным. Только вот "до кондиции" ему ещё далековато... Потом речь идёт не о том, чтобы "сделать", а о том, чтобы портировать готовое. Т.е. на С и если говорить о sPEEX vbr - то во float.Ага, и при этом головой абсолютно не думать. Лафа, паньмаешш, мечта "имбедецила". ...Или пользоваться суррогатными типами если нужно сделать за так и быстро :-) Тянет примерно один порядок.А один порядок - это сколько? По-моему, даже любой суррогатный тип уменьшит быстродействие DSP на типовых операциях значительно более 8-10 раз. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fontp 0 4 апреля, 2008 Опубликовано 4 апреля, 2008 · Жалоба Не знаю, может, сэмплы неудачные, но по мне, так SPEEX 6 кб/с звучит значительно хуже G 723.1 5.3 кб/с. Кроме того, G723.1 - это не CELP, которым, как известно, является FS-1016, и SPEEX очень похож на него. Мне показалось, что никак уж не хуже SPEEX на нижнем битрейте. Интересно, а за счёт чего он будет звучать лучше, скажем, того же FS-1016? С 6.3 я погорячился, исправил на 5.3 ещё до Вашего поста. G723.1 (5.3) - это ACELP, c FS-1016 одного поля ягода. "A" в ACELP влияет на скорость поиска, но не на размер таблицы, а значит качество звучания Слушать SPEEX нужно в соответствующем диапазоне > 4.8. На нижнем диапазоне 2.4 его лучше вообще не слушать. Вообще-то главным образом качество CELP зависит от того как сделан поиск по стохастической кодовой книге - с разорваной обратной связью или без разорваной (разница между G729 и G729A) Т.е. полный перебор или декомпозиция "переборов" При одинаковых битрейтах качество зависит ещё от тщательности и развесистости векторного квантования.Не знаю уж, где оно лучше исполнено. А так всё примерно одинаково (FS1016, SPEEX, G723/1 - 5.3) - линейные предсказания, спектральные пары, кодовые книги и т.д. Примерно одна фигня А один порядок - это сколько? По-моему, даже любой суррогатный тип уменьшит быстродействие DSP на типовых операциях значительно более 8-10 раз. Да ладно. Посмотрите как написано в FastFloat16 в соответствующем EE185 для BF Мантиссы умножил, порядки сложил - вот и умножение Нормализовал операнды к большему порядку, сложил мантиссы - вот и сложение Или деление. Фигня. Нормализация и целочисленное деление. Нормализация у BF - это две операции, норм и шифт. На ADSP2105, понятно, ничего не получится, нет там аппаратной нормализации :-) Всё инлайн. Без проверок переполнения и потери точности. В 10 раз даже много. Нет, ну за три такта тоже не получится, конечно Относительная точность - лучше 10**-4. Но это относительная точность, не абсолютная, как у fixed16. Практически всегда достаточно такой, чего нельзя сказать про fixed16 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 4 апреля, 2008 Опубликовано 4 апреля, 2008 (изменено) · Жалоба Господа, ну послушайте не сэмплы с сайта, которые действительно ужасно звучат(они просто закодированы/раскодированы на стандартных настройках кодера), а проведите эксперимент самостоятельно. VBR дает обалденное качество на 4Кб/с, по сравнению с другими! Ну может быть посоветуйте что-нибудь, чтобы было не хуже GSM по субъективным оценкам пользователей, но на скорости не более 4.5. Задача вообще решаема? GSM очень расточителен(целых 13Кб/с!) Да, халява это приятно всегда. Блин, а этот шарк аж 370мА захавывает - это очень много для меня(батарейка мобилы просто умрет за часок-другой). Изменено 4 апреля, 2008 пользователем sigmaN Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
