Как добиться бесперебойной работы аудио при большой нагрузке?
если аудиопроигрыватель майкрософтовский - возможно, что-нибудь есть
иначе, лучше обращаться в техподдержку аудиопроигрывателя, который ты используешь
я бы, наверное, в таком случае ответил "никак" из вежливости =)
иначе, лучше обращаться в техподдержку аудиопроигрывателя, который ты используешь
я бы, наверное, в таком случае ответил "никак" из вежливости =)
там ответят ждать следующей версии винды 
кстати WMP при проигрывании музыки очень неплохо переживает большые нагрузки на проц и винт (с видео уже конечно больше проблем)
думаю можно найти плагин, который повышает приоритет процесса
пишется этот плагин очень лекго (это всего лишь inproc COM компонет, который при создании и разрушении увеличивает и соотв уменьшает приоритет процесса)
если очень хочется, то можно поставить Media SDK, там будет визард, с пом его генерируешь background plugin
там будут два пустих метода, куда можно вписать изменения приоритета
кстати WMP при проигрывании музыки очень неплохо переживает большые нагрузки на проц и винт (с видео уже конечно больше проблем)
думаю можно найти плагин, который повышает приоритет процесса
пишется этот плагин очень лекго (это всего лишь inproc COM компонет, который при создании и разрушении увеличивает и соотв уменьшает приоритет процесса)
если очень хочется, то можно поставить Media SDK, там будет визард, с пом его генерируешь background plugin
там будут два пустих метода, куда можно вписать изменения приоритета
Я юзаю STP. Он позволяет менять собственный приоритет - иногда это ощущается, а иногда - нет.
Для аудио-проигрывателя важнее i/o priority - есть такая штука в виндах ?
не видел. и в унихе своём не видел - правда, и повода не было.
Для аудио-проигрывателя важнее i/o priority - есть такая штука в виндах ?Нет, вроде
Зато в Longhorn появиятся определенные фишки. Типа можно будет забивать определенное кол-во мощи проца и io, которое будет гарантировано доставаться потоку.
Longhorn - это фантастика.
Типа можно будет забивать определенное кол-во мощи проца и io, которое будет гарантировано доставаться потоку.Скорее всего, для этого им потребуется поддержка со стороны процессора, ибо в тех же никсах на подобный вопрос отвечают что-то вроде "не представляется возможным".
В твоём унихе у этой задачи есть единственное назначение:
пихать музыку в /dev/dsp*.
Поэтому её приоритет совпадает с приоритетом ввода-вывода.
---
...Я работаю антинаучным аферистом...
пихать музыку в /dev/dsp*.
Поэтому её приоритет совпадает с приоритетом ввода-вывода.
---
...Я работаю антинаучным аферистом...
Неверно. Это лишь третье назначение. Первое - считывание музыки в закодированном виде с винта, второе - декодирование (включая эффекты).
Зато в Longhorn появиятся определенные фишки. Типа можно будет забивать определенное кол-во мощи проца и io, которое будет гарантировано доставаться потоку.В FreeBSD 8.0 или Linux 2.10.0 и не такие фишки будут.
Не знаю. Я в этом мало понимаю. Но, что мешает просто учитывать это шедулером. Давать сначала проц время застолбившим потокам, а потом уже согласно приоритетам.
Тут ведь еще проблема в проигрывателем в том, что винда повышает приоритет потока с активным окошком. Получается, что если ты разбтаешь с прогой, которая сильно проц нагружает, то она еще к тому же будет иметь боле высокий приоритет чем твой плеер, который висит на заднем плане. Увеличение приоритета процесса плеера эту проблему решает.
В Longhorn у них задача обеспечить плавность анимации, чтобы не дергалась. Даже если все это будет хорошо ускорятся аппаратно, т.е. в общем все это обилие анимации не будет жрать большой процент проц мощи, нужно регулярно управлять этим процессом анимации. Получается, что нужно мало проц мощности, но часто. Понятно, что управление чрез приоритет это не совсем то в этом случае. Короче интересно, что у них получится.
Тут ведь еще проблема в проигрывателем в том, что винда повышает приоритет потока с активным окошком. Получается, что если ты разбтаешь с прогой, которая сильно проц нагружает, то она еще к тому же будет иметь боле высокий приоритет чем твой плеер, который висит на заднем плане. Увеличение приоритета процесса плеера эту проблему решает.
В Longhorn у них задача обеспечить плавность анимации, чтобы не дергалась. Даже если все это будет хорошо ускорятся аппаратно, т.е. в общем все это обилие анимации не будет жрать большой процент проц мощи, нужно регулярно управлять этим процессом анимации. Получается, что нужно мало проц мощности, но часто. Понятно, что управление чрез приоритет это не совсем то в этом случае. Короче интересно, что у них получится.
Ну расскажи. Просвети, так сказать.
Увеличение приоритета процесса плеера эту проблему решает.Ставил real time. До определённого момента помогает, но не более того.
Получается, что нужно мало проц мощности, но часто.в БСД эта проблема решается строкой в ядре HZ = 1000 - частота переключения между процессами.
Нее... Боюсь, мелкософтовцы без двухъядерных процессоров не обойдутся
Любопытно как моллюски будут пихать нераскодированные данные в свой /dev/dsp*.
В рамках данной задачи это (почти) одно и то же.
---
...Я работаю антинаучным аферистом...
В рамках данной задачи это (почти) одно и то же.
---
...Я работаю антинаучным аферистом...
Только надо обещать Linux 3.x.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Задача _считывания_ с винта, который может быть under heavy load, намеренно пропущена? Собсно, всё из-за неё.
в БСД эта проблема решается строкой в ядре HZ = 1000 - частота переключения между процессамиИ что это решает проблему. Двадцать потоков будут гарантированно получать по 1% проц мощи каждую секунду, если при этом остальные 80% жрут другие проги. Что-то я в этом сомневаюсь.
Ведь нужно переключать не чаще, а "разумнее". Сегодня шедулер оперирует в терминах приоритетов. А это управление в относительных терминах. А для анимации нужны определенные гарантии без относительно того, какая общая нагрузка на проц в данный момент.
С приоритетами каждый тянет одеяло на себя. Можно конечно сделать реал тайм приоритет, делать что нужно, а потом засыпать до следующего раза. Но эта схема плохо работает, когда тебе нужно 20 таких потоков.
> Собсно, всё из-за неё.
Не только, ещё memory pressure норовит вытеснить страницы памяти, используемые игралкой.
Не только, ещё memory pressure норовит вытеснить страницы памяти, используемые игралкой.
Задача _считывания_ с винта, который может быть under heavy load, намеренно пропущена? Собсно, всё из-за неё.С этим собираются поступать аналогично.
А для анимации нужны определенные гарантии без относительно того, какая общая нагрузка на проц в данный момент.Операционная система, в которой память может быть высвоплена не может давать никаких гарантий.
>> Задача _считывания_ с винта, который может быть under heavy load, намеренно пропущена? Собсно, всё из-за неё.
> С этим собираются поступать аналогично.
И получится хуйня. Во сколько порядков различается время переключения контекста процессора и время перемешения головки винта?
> С этим собираются поступать аналогично.
И получится хуйня. Во сколько порядков различается время переключения контекста процессора и время перемешения головки винта?
Почему же? А если в ней есть механизм для фиксирования страниц в памяти?
Да, но мало вероятно, что с этим могут быть проблемы у проги, которая регулятно эту память юзает.
На самом деле, это тоже не вопрос.
Надо забацать что-то наподобие
---
...Я работаю антинаучным аферистом...
Надо забацать что-то наподобие
nice -n read-pri cat /there/this.mp3 | nice -n dec-pri mpg321 -s - | nice -n play-pri mpg321 -
---
...Я работаю антинаучным аферистом...
И получится хуйня. Во сколько порядков различается время переключения контекста процессора и время перемешения головки винта?Просто сегодня запросы на io иду в очередь запросов, а потом в каком-то порядке выполняются. Соответственно можно как-то помечать запросы, чтобы согласно определенным квотам отдавать предпочтение сначала помеченным запросам.
> Почему же? А если в ней есть механизм для фиксирования страниц в памяти?
Это конечно лечит. Но вот можно ли сделать mlock не на heap, а на свой собственный text?
Это конечно лечит. Но вот можно ли сделать mlock не на heap, а на свой собственный text?
> Да, но мало вероятно, что с этим могут быть проблемы у проги, которая регулятно эту память юзает.
Вот и ощути разницу между "мало вероятно", и "гарантировать".
Вот и ощути разницу между "мало вероятно", и "гарантировать".
Конечно, можно.
Но если прога выделяет дополнительную память во время работы, то тут гарантия кончается.
Нужно заранее выделить всю память, что плохо совмещается с использованием языков высокого уровня,
в которых память выделяется незаметно для разработчика.
Но если прога выделяет дополнительную память во время работы, то тут гарантия кончается.
Нужно заранее выделить всю память, что плохо совмещается с использованием языков высокого уровня,
в которых память выделяется незаметно для разработчика.
А за гарантии, как сказано выше в треде, надо платить.
В данном случае - взять ОСРВ, и соответствующие приложения для неё.
В данном случае - взять ОСРВ, и соответствующие приложения для неё.
А почему? во всяком случае в С++ ты можешь написать свой собственный аллокатор, который берет память из залоченного участка.
> во всяком случае в С++ ты можешь написать свой собственный аллокатор, который берет память из залоченного участка
Как ты узнаешь, сколько памяти надо зарезервировать?
Как ты узнаешь, сколько памяти надо зарезервировать?
А в Си не можешь?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Ыыыыыыыыы.... А почему ее надо резервировать? Я видимо чего-то не догоняю.
Как бы, голова для этого есть.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Просто сегодня запросы на io иду в очередь запросов, а потом в каком-то порядке выполняются. Соответственно можно как-то помечать запросы, чтобы согласно определенным квотам отдавать предпочтение сначала помеченным запросам.Назови мне IO систему, которая гарантирует время ответа.
Потому что, если в процессе проигрования фильма потребуется дополнительная память, неизвестно, сколько времени потребуется на её выделение.
> Назови мне IO систему, которая гарантирует время ответа.
Сначала надо назвать, какая модель жёсткого диска гарантирует время ответа (при своей исправности
потом, какой контроллер и шина ввода/вывода гарантируют время доставки данных в память.
У диска может быть куча запросов в очереди, шину могут надолго занять другие приложения.
Но домохозяйкам гарантия не нужна, иначе они не использовали бы систему,
в EULA к которой содержится полный WARRANTY DISCLAIMER.
Сначала надо назвать, какая модель жёсткого диска гарантирует время ответа (при своей исправности
потом, какой контроллер и шина ввода/вывода гарантируют время доставки данных в память.
У диска может быть куча запросов в очереди, шину могут надолго занять другие приложения.
Но домохозяйкам гарантия не нужна, иначе они не использовали бы систему,
в EULA к которой содержится полный WARRANTY DISCLAIMER.
Если память, к которой обрашается прога по несколько раз в сек, вытесняется в своп, то значит в системе большие траблы в наличием достаточного кол-ва оперативки. Какая тут плавная анимация.
Хотя тоже можно ввести понятие гарантированной памяти. Т.е. локать, но не давать залокать больше 80% оперативки.
Хотя тоже можно ввести понятие гарантированной памяти. Т.е. локать, но не давать залокать больше 80% оперативки.
Если память, к которой обрашается прога по несколько раз в сек, вытесняется в своп, то значит в системе большие траблы в наличием достаточного кол-ва оперативки. Какая тут плавная анимация.Вот видишь, не каких гарантий.
Хотя тоже можно ввести понятие гарантированной памяти. Т.е. локать, но не давать залокать больше 80% оперативки.И так разрешить каждому процессу?
Использовать для этого голову и значит заниматься низкоуровневым программированием, со всеми вытекающими последствиями.
Real-time operating systems, on the other hand, solve this quandry by altogether avoiding both memory fragmentation and "garbage collection", and their consequences. RTOSs offer non-fragmenting memory allocation techniques instead of heaps. They do this by limiting the variety of memory chunk sizes they make available to application software. While this approach is less flexible than the approach taken by memory heaps, they do avoid external memory fragmentation and avoid the need for defragmentation. For example, the "Pools" memory allocation mechanism allows application software to allocate chunks of memory of perhaps 4 or 8 different buffer sizes per pool. Pools totally avoid external memory fragmentation, by not permitting a buffer that is returned to the pool to be broken into smaller buffers in the future. Instead, when a buffer is returned the pool, it is put onto a "free buffer list" of buffers of its own size that are available for future re-use at their original buffer size. This is shown in Figure 7.
Figure 7: A Memory Pool's Free Buffer Lists
Memory is allocated and de-allocated from a pool with deterministic, often constant, timing.
Figure 7: A Memory Pool's Free Buffer Lists
Memory is allocated and de-allocated from a pool with deterministic, often constant, timing.
Для того, чтобы определить объём памяти для проигрывания одной
песни, совершенно не надо заниматься низкоуровневым
программированием.
Со всеми вытекающими последствиями.
---
...Я работаю антинаучным аферистом...
песни, совершенно не надо заниматься низкоуровневым
программированием.
Со всеми вытекающими последствиями.
---
...Я работаю антинаучным аферистом...
Угу.
RTOS, а не Windows.
С приложениями, которые довольствуются memory chunks of limited variety вместо обычной кучи.
RTOS, а не Windows.
С приложениями, которые довольствуются memory chunks of limited variety вместо обычной кучи.
> Вот видишь, не каких гарантий.
> И так разрешить каждому процессу?
Вот ты смеёшься, а примерно так и сделают.
И что характерно, у домохозяек фильмы будут играться без пауз.
А у тебя - нет, потому что ты захочешь, чтоб в фоне скажем cvsup работал,
и раздавались другие фильмы по домашней локалке со скоростью 1Гбит/c,
да ещё и компилировалось что-нибудь.
> И так разрешить каждому процессу?
Вот ты смеёшься, а примерно так и сделают.
И что характерно, у домохозяек фильмы будут играться без пауз.
А у тебя - нет, потому что ты захочешь, чтоб в фоне скажем cvsup работал,
и раздавались другие фильмы по домашней локалке со скоростью 1Гбит/c,
да ещё и компилировалось что-нибудь.
> Для того, чтобы определить объём памяти для проигрывания одной
> песни, совершенно не надо заниматься низкоуровневым
> программированием.
И сколько памяти нужно для Windows Media Player?
> песни, совершенно не надо заниматься низкоуровневым
> программированием.
И сколько памяти нужно для Windows Media Player?
1. Откуда я знаю?
2. Меня это волнует?
---
...Я работаю антинаучным аферистом...
2. Меня это волнует?
---
...Я работаю антинаучным аферистом...
Назови мне IO систему, которая гарантирует время ответа.Тут имеется в виду, что тебе будет гарантировано, что предпочтение в доступе к винту получат проги, которым важно получать регулярно данные, а не те, которым все равно на пол секунды раньше или позже.
Как мне кажется, что с такими механизмами (какой-то гарантированный доступ к процу и диску плеер сможет, используя кэши определенного размера, выдавать плавную анимацию при довольно больших нагрузках на систему. Этого сегодня нет. Никто не собирается делать эти механизми идеальными. Ничего страшного, если при запуске какой-нибудь проги плеер пропустит пару кадров.
> 1. Откуда я знаю?
Вот и никто не знает.
> 2. Меня это волнует?
Никого не волнует. Поэтому проигрывание иногда затыкается.
Вот и никто не знает.
> 2. Меня это волнует?
Никого не волнует. Поэтому проигрывание иногда затыкается.
Проблемы с выделение памяти тоже можно решить так или иначе. Например, с запасом выделять память, и если запас уменьшается, то параллельно основному потоку этот запас пополнять. Идея аналогичная тредпулу.
Блин. Тут говорят о гарантированности. Это решение не обеспечивает никаких гарантий.
При определенных условиях обеспечит. А кто сказал, что целесообразно обеспечивать более сильные гарантии. Сегодня вообще никто ничего не обеспечивает. Что-то можно сделать сегодня, но с очень большими усилиями. А так хоть появится api и поддержка со стороне кернеля. Собственно я только про этом и хотел сказать, когда упомянул новые фичи Longhorna.
Тебе уже указали: про новые фичи Longhorna не надо.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
я не заметил
> я не заметил
FreeBSD 8.0 и Linux 2.10.0 были шуткой
FreeBSD 8.0 и Linux 2.10.0 были шуткой
> Тут говорят о гарантированности. Это решение не обеспечивает никаких гарантий.
"Гарантии" тут понимаются общепринятым в IT-индустрии образом: никаких гарантий.
"Гарантии" тут понимаются общепринятым в IT-индустрии образом: никаких гарантий.
Except for the Limited Warranty and to the maximum extent permitted by applicable law, Microsoft and its suppliers provide the Productand support services (if any) AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the Product, and the provision of or failure to provide support or other services, information, software, and related content through the Product or otherwise arising out of the use of the Product.
Тем не менее, Longhorn-а нет точно так же, как и FreeLSD 8.0.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
летом должна быть бета 1
1. До лета ещё далеко.
2. К лету навыходит столько разных альф и бет.
---
...Я работаю антинаучным аферистом...
2. К лету навыходит столько разных альф и бет.
---
...Я работаю антинаучным аферистом...
Млин, под 800 мегов оперативы, а винда всё равно свопится 
Поясню ещё раз: в БСД послушать музыку без перебоев почему-то гораздо проще, нежели в винде - уже сейчас. Да вот вопрос: что можно делать на компе под виндой, если с компа скачивают фильмы в 40 потоков? При условии, что винт в системе единственный и ему уже три года, то есть особой скоростью работы он не отличается (5400 оборотов).
Я вот своп отключаю, тогда винда гораздо лучше себя ведет. У нее какая-то болезь свопится постоянно, причем в самые неподходящие моменты.
Про шары - это да, проблема. Нет вообще почти никаких настроек. И bandwidthcontroller не во всем помогает. Отойдешь от компа на пару минут, так даже при bandwidthcontroler все твои проги вытеснены в своп.
Короче маза одна: купить гиг оперативки и отключить своп.
Про шары - это да, проблема. Нет вообще почти никаких настроек. И bandwidthcontroller не во всем помогает. Отойдешь от компа на пару минут, так даже при bandwidthcontroler все твои проги вытеснены в своп.
Короче маза одна: купить гиг оперативки и отключить своп.
> Короче маза одна: купить гиг оперативки и отключить своп.
И ждать Longhorn.
И ждать Longhorn.
тогда лучше еще гиг прикупить
Поясню ещё раз: в БСД послушать музыку без перебоев почему-то гораздо проще, нежели в винде - уже сейчас.Как ? HZ = 1000 ?
> Как ? HZ = 1000 ?
Через rtprio.
Через rtprio.
А мб мелкомягкие решат проблему аппаратно?
Например, мамки, рекомендуемые под лонгхорн, будут нести в своем конструктиве аппаратный mp3-плеер
Например, мамки, рекомендуемые под лонгхорн, будут нести в своем конструктиве аппаратный mp3-плеер
> Например, мамки, рекомендуемые под лонгхорн, будут нести в своем конструктиве аппаратный mp3-плеер
И отдельный винчестер, на котором будут храниться только mp3.
И отдельный винчестер, на котором будут храниться только mp3.
И отдельный винчестер, на котором будут храниться только mp3.Не обязательно.
Достаточно иметь свою память (можно даже не флаш)
128-256 Мб вполне достаточно.
Всем: может быть это будет вам интересно. В Линукс недавно появились несколько патчей, динамически меняющих некоторые системные параметры по генетическому алгоритму. Утверждается, что скоросто прогона тестов возрасла примерно на 2%, и значительно повысилась интерактивность(т.е. уменьшилась латентность, что является немаловажным фактором для мультимедиа приложений). http://kerneltrap.org/node/4751#comment
HZ = 100 
Я не знаю, почему так, но когда с меня качают в 40 потоков под БСД, у меня не возникает желания отойти от компьютера. Всё просто работает, хоть реакция GUI и помедленней.
Я не знаю, почему так, но когда с меня качают в 40 потоков под БСД, у меня не возникает желания отойти от компьютера. Всё просто работает, хоть реакция GUI и помедленней.
Кстати дефолт уже 1000.
Да, мне mplayer об этом постоянно напоминает, только руки как-то не доходят 
Я вот подумал, тонкостей не знаю, но такое возможно в напалме.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Оставить комментарий
hoha32
А там есть ответ на вопрос "Как добиться бесперебойной работы аудиопроигрывателя при большой нагрузке на процессор и дисковую подсистему?"