LINUX.ORG.RU
Форум — Talks  

ALSA vs OSS(snd_pcm_oss), OSS WINS!


0

0

msi wind u90x, slackware-current

для начала насквозь оптимизированный mplayer:

mplayer -ao alsa 07 - Electro Sun - In My Dream (album edit).ogg
рядом в окошке top показывает ~5% CPU для процесса mplayer

mplayer -ao oss 07 - Electro Sun - In My Dream (album edit).ogg
top показывает 4% в начале а далее 0% CPU

очень похоже пашет sox
AUDIODRIVER=alsa play 07 - Electro Sun - In My Dream (album edit).ogg
15%-19% CPU

AUDIODRIVER=oss play 07 - Electro Sun - In My Dream (album edit).ogg
6%-7% CPU

круто


← Силикон на изоляторе: наноракеты из нанополупроводников
Плата за газ →

Очень круто. Учитывая, что на современных системах oss эмулируется с помощью alsa.

Если это всё же честный oss, то ничего удивительного: посмотрите ради интереса, как оно в ядре устроено. (:

env ★★☆
()
Ответ на: комментарий от env

нет, это OSS который эмулирован дровами ALSA

bomj
() автор топика
Ответ на: комментарий от reliktt

действительно

[reliktt@arch downloads]$ mplayer -ao alsa 'Golden Skans.mp3'
MPlayer SVN-r29319-4.5.0 (C) 2000-2009 MPlayer Team
137 audio & 296 video codecs

Playing Golden Skans.mp3.
Audio only file format detected.
Clip info:
Title: Golden Skans
Artist: Klaxons
Album: Myths Of The Near Future
Year: 2007
Track: 3
Genre: Other
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 320.0 kbit/22.68% (ratio: 40000->176400)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 40.4 (40.4) of 181.0 (03:01.0) 1.0%


AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 20.7 (20.7) of 181.0 (03:01.0) 0.6%

reliktt ★
()
Ответ на: комментарий от reliktt 

>> 4.5.0

/me задумался об обновлении gcc до 4.4.0

Andru ★★★★
()

троллоло, нука запусти одновременно два мплейера через oss и узнай силу одноканального смешения

lester_dev ★★★★★
()

Элементарно, Ватсон! Внутри libasound (юзерспейсная библиотека ALSA) по умолчанию работают несколько полезных плагинов: обычно это plug (который умеет ресемплировать поток, если запрошенная частота дискретизации не поддерживается железкой) и dmix (который смешивает потоки от нескольких приложений). А в случае OSS (и даже эмуляции OSS через ALSA) mplayer передаёт поток сразу в ядро, без всяких юзерспейсных прослоек.

Deleted
()

А теперь одень наушники от 3000 руб и послушай "качество" передискретизации на oss.

linux4ever
()

У меня в конфиге mplayer уже давно pulse.

Paul_N
()
Ответ на: комментарий от linux4ever 

>У меня mplayer через jack ест меньше 1%, oss 3% ЧЯДНТ? Процессор Pentium 4 3Ghz.

а сам джек скольк ест?

Khades ★★
()
Ответ на: комментарий от linux4ever

> У меня mplayer через jack ест меньше 1%, oss 3% ЧЯДНТ? Процессор Pentium 4 3Ghz.

А сколько при этом ест jack =)?

Deleted
()

У меня тоже oss есть меньше проца, нежели alsa, поэтому всегда юзаю его (в mocp, mplayer и др.)

paxac ★
()

Главное забыл спросить. А зачем это все? Пиписьками померяться, или музыку на 386 послушать?

ist76 ★★★★★
()
Ответ на: комментарий от ist76

> Главное забыл спросить. А зачем это все? Пиписьками померяться, или музыку на 386 послушать?

Это из серии "экономим два мегабайта памяти, когда свободно три гига".

Deleted
()
Ответ на: комментарий от Deleted

у каждого своя история... когда есть 2 приложения/сервиса/продукта, исполняющих одну и ту же работу, но затрачивающих на это разное количество ресурсов - очень разумно спросить: "А что здесь, собственно, происходит?".

Дальше ЛОРа это обсуждение вряд ли выйдет, но в общем случае подобные вопросы могут привести к улучшению некоторых из рассматриваемых приложений/сервисов/продуктов.

spunky ★★
()

UPD: после явного указания в .asoundrc выводить звук прямо на нужные девайсы, alsa и alsa-oss сравнялись по скорости работы...
вывод: dmix жуткий тормоз в alsa

bomj
() автор топика
Ответ на: комментарий от Deleted

>> Главное забыл спросить. А зачем это все? Пиписьками померяться, или музыку на 386 послушать?

>Это из серии "экономим два мегабайта памяти, когда свободно три гига".

Именно такие рассуждения и приводят к появлению гавенного кода. "Нафига писать хорошо, если и так работать будет?"

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

> Именно такие рассуждения и приводят к появлению гавенного кода. "Нафига писать хорошо, если и так работать будет?"

Те же рассуждения гораздо чаще приводят к увеличению функциональности. В контексте топика, сравнивать ALSA и OSS - это примерно как сравнивать vim и cat.

Deleted
()
Ответ на: комментарий от Deleted

>> Именно такие рассуждения и приводят к появлению гавенного кода. "Нафига писать хорошо, если и так работать будет?"

>Те же рассуждения гораздо чаще приводят к увеличению функциональности. В контексте топика, сравнивать ALSA и OSS - это примерно как сравнивать vim и cat.

Увеличение функциональности очень редко влечет за собой увеличение потребления ресурсов.

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

> Увеличение функциональности очень редко влечет за собой увеличение потребления ресурсов.

Приведи реальный пример, когда увеличение функциональности не влечёт за собой увеличение потребления ресурсов. Как минимум, увеличивается количество кода -> увеличивается размер бинарника -> увелчивается потребление места на диске и памяти.

Deleted
()
Ответ на: комментарий от Deleted

>Приведи реальный пример, когда увеличение функциональности не влечёт за собой увеличение потребления ресурсов.

linux kernel, KDE (по большей части), opera. Это навскидку.

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

>> Приведи реальный пример, когда увеличение функциональности не влечёт за собой увеличение потребления ресурсов.

> linux kernel, KDE (по большей части), opera. Это навскидку.

Ты уверен?..

Deleted
()
Ответ на: комментарий от Deleted

>>> Приведи реальный пример, когда увеличение функциональности не влечёт за собой увеличение потребления ресурсов.

>> linux kernel, KDE (по большей части), opera. Это навскидку.

>Ты уверен?..

Про kernel - уверен на 100%. Ускорение заметно даже на глаз. Opera - тоже.

KDE если и не ускоряется (что временами таки происходит), то по крайней мере не "затормаживается".

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

> Про kernel - уверен на 100%. Ускорение заметно даже на глаз. Opera - тоже.

Под ресурсами системы я подразумевал не только процессорное время. Потребление оперативной памяти увеличилось во всех, указанных тобой примерах. А по поводу ускорения можно и поспорить. Например однопоточный дисковый IO на ядре 2.4 будет работать быстрее, чем на 2.6.

Deleted
()
Ответ на: комментарий от Deleted

>> Про kernel - уверен на 100%. Ускорение заметно даже на глаз. Opera - тоже.

>Под ресурсами системы я подразумевал не только процессорное время. Потребление оперативной памяти увеличилось во всех, указанных тобой

Давай спорить. Где увеличилось потребдение памяти? Ни в одном не увеличилось.

>поводу ускорения можно и поспорить. Например однопоточный дисковый IO на ядре 2.4 будет работать быстрее, чем на 2.6.

Это смотря какой шедулер поставишь. В 2.4 просто других нет :)

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

>>Под ресурсами системы я подразумевал не только процессорное время. Потребление оперативной памяти увеличилось во всех, указанных тобой

>Давай спорить. Где увеличилось потребдение памяти? Ни в одном не увеличилось.

Про kernel можно даже не спорить. Там и так все понятно. В KDE в 3.5.10 уменьшилось. В Опере тоже.

dikiy ★★☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Силикон на изоляторе: наноракеты из нанополупроводников
Talks
Плата за газ →