По темата - разбира се, че аналоговия звук си е аналогов звук. И разбира се, че когато се цифровизира /дискретизира/ се губи информация. Точно за това хората въведоха формати /енкодери/ без загуба на качество (което е лъжа, ама карай). Все пак нашето ухо не е толкова чувствително за да определи разликата между 24 и 32 битов звук, но в интерес на истината ние /хората/ не възприемаме музиката само с ушите. Така, че разлика има и тя се усеща. От някои повече, от някои по-малко.

Да, някои хора дори "виждат" музика, има медицински термин за това - синестезия - обикновено се случва при мозъчни травми, тумори или под въздействието на халюциногени.

Та изобщо не изключвам странностите на човешките възприятия. Аз дори мисля още нещо - дали пък в конкретния случай не е намесен плацебо ефекта? Представям си такъв експеримент, хващат три групи хора - такива, които изобщо не знаят какво е 24/32-битов звук, такива които имат някаква идея, както и такива, които са убедени че ще направят разлика (например аудиофили). И съответно им пускат едно и също парче - семплирано на 24 бита и на 32 бита. Провеждащият теста го прави индивидуално с всеки един участник, като ги информира кое е 24-битово и кое е 32-битово. Но за по-забавно, той им казва кое е 24-битовото и кое е 32-битовото правилно само в 50% от случаите, в останалите съзнателно ги лъже. Ще е супер забавно накрая да се сравнят резултатите в двата случая и при трите групи тестови субекти.

Не мога да повярвам че никой не се е сетил да направи нещо подобно.

Преконвертирай флак 16, 24 бита  на wav 32 бита float , ако не чуеш разликата, не трябва да коментираме точно  този въпрос.

Конвертирай яко намачкан JPEG с ниско качество в PNG и виж разликата, горе-долу същата история

Че за какво му е на някой 32-битов звук, то първо няма какво да пуснеш семплирано на 32-бита, второ е абсолютно безсмислено това, колко dynamic range отгоре на 24-битовия звук ще изкараш - аз първо много се съмнявам някой човек да може да установи каквато и да било разлика (аудиофилите могат де, те имат  специални уши), но също и съмнява ме дори самите високоговорители да са способни да го възпроизведат, освен ако не са някакви специални.

Същото и за 384-те khz sample rate, wtf е това, кой въобще го интересува, концерт за прилепи ли ще правим. Ей това аудио-индустрията е голямата свинщина и яко хайпове определено, защо ли производителите на дискове и РАМ памети не бяха и те така, нямам нищо напротив терабайтови RAM памети и екзабайтови SSD дискове с дебели широки шини ей така щото сме ценители и имаме нужди.

Аз единствените лампи съм ги виждал в едно старо (немско?) радио което баба ми имаше неблагоразумието да изхвърли, сега сигурно щеше да има прилична антикварна стойност - обаче аз го разфасовах тогава преди да замине на боклука - лампите специално ги строших в една тухлена стена, защото ми се виждаше много забавно.

А, всъщност и в телевизор съм виждал лампи - в стария големия Електрон от соца със сигурност имаше.

Сега трябва да се чувствам млад

Мне, единственият опит с това ми е отпреди много време, когато държахме прикачените файлове за наш webmail в mysql база. Тогава ползвахме myisam, innodb не помня дали съществуваше, и да е имало трябва да е било новост. Отказахме се (програмистите пренаписаха нещото така че да пази файлове) заради две неща - бекъпите взеха да се влачат грозно, а при срив и скапана база, myisamchk минаваше за часове, дали не и дни. Innodb щеше да ни реши единия от двата проблема. След това никога не ми е минавало през главата да го правя. Единственото удобство е че базата ти гарантира консистентността на данните - няма да имаш останали файлове, за които няма запис в базата или обратното - записи срещу липсващи файлове, цялата мъка която иначе приложението би трябвало да прави - като например при неуспешна DB операция, това да се отчете и върху файла и т.н.

Това го заплащаш с цената на производителност, като не че няма какво да направиш, ама каквото и да направиш, няма как базата да стане по-бърза от файловата система. Да не говорим че трябва много да внимаваш как си организираш таблиците (да нашиеш blob-овете заедно с всички други метаданни в една единствена голяма таблица скоро ще те утрепе, представи си един SELECT отгоре какво прави).

Колкото и умно да го измислиш обаче, просто DBMS-ите не са мислени да държат огромни BLOB-ове, това им е просто някакъв много частен случаи, докато файловите системи са правени с тази идея изначално. Дори първоначално да нямаш много проблеми, с времето фрагментацията нараства и базата няма да управлява това по-добре от една файлова система.

Това отсега мога да ти кажа че дори да замени успешно полупроводниковите транзистори, няма шансове да пробие в обществото на аудиофилите, поради ред причини - не е обемно, не хаби достатъчно електроенергия, не издава тих жужащ звук, не свети и най-важното: няма ретро вид.

А пък ако излезе и евтино да произведеш нанолампов усилвател - това му е смъртната присъда.

Значи жалко че няма по-стара технология от ламповите усилватели - щеше да свири още по-добре (и да струва повече пари разбира се).

Хаха ебавай се ти ама някои хора хубави пари правят от това....идеята да си маркетират продукцията като скрапната от руска космическа техника е просто велика

Ще държиш по 1-2 гигабайта blob-ове в базата? Звучи като рецепта за драма

А иначе ползването на swap-а е бавно, сега зависи от скоростта на RAM паметта, както и диска. Разликата обикновено в порядъка на няколко хиляди пъти, макар че със SSD нещата може да не са чак толкова радикални. Проблемът обаче е че ти няма как да контролираш достатъчно добре какво да влиза в swap-а и какво не, никой не е казал че трябва да е огромния обект, а не примерно text сегмента (изпълнимия код) на софтуера който върви на машината, затова и резултатите може да са абсолютно непредсказуеми. Съвсем отделно че kernel thread-овете дето се занимават с обслужването на swap паметта, ще изреват на умряло ако трябва да се занимават с обеми памет от порядъка на 20GB и ще заемат прилично много процесорно време докато се занимават с това. Като цяло, RAM паметта е евтина в днешно време, аз бих гледал да разчитам колкото може по-малко на swap.

А стига ве....а дебели тройно екранирани с златни нишки кабели по 100 лева метъра има ли, така да не се внасят паразитни смущения, които да развалят хубавия звук?

Ако си на 64бит архитектура, едва ли изобщо ще се усети някаква разлика. Едно време имаше големи архитектурни промени в процесорите- добавяха нови инструкции, регистри. Сега Интел прави само козметики, оптимизации и вдигане броя на ядрата.

И сега има. AVX512 примерно с 512-битовите SIMD регистри и съответно нови 16 xmm регистъра. Или разширенията за транзакционна памет.

Ммм другият момент според мен идва оттам че ядрата от сорс можеш да ги билдваш с по-нови версии на gcc, отколкото пакетираните - а в тях съответно може да има подобрения по оптимизациите, подобрения по генерирания код за архитектурата и т.н. Но със съшият успех може да има и регресии, които генерират бъглив код

просто с ръчно компилираното се усеща прираст в производителноста, а на мен от време на време ми трябва да съм на максимум...

Аз пък страдам от липса на въображение и все не мога да усетя тоя прираст на производителност. Нито пък виждам откъде ще ми дойде. Това, че ще орежа модулите с нищо няма да промени положението. А, услугите и без това са ми орязани до крайност.

Идва оттам че го компилираш оптимизирано за процесора ти (дали ще е да се ползват SIMD разширения като SSE2/3/4 или AVX, дали ще генерира по-оптимален код спрямо това което компилаторът знае за латентност на инструкции на конкретния процесор, където може да замести някоя инструкция с друга или комбинация, дето са по-бързи, дали ще има правилни предположения за cacheline и alignment, дали ще достъпва паметта по-оптимално с оглед на процесорните кешове по-ефективно). Пребилднатите ядра в репата на дистрибуциите обикновено са компилирани за generic x86 или x86_64 таргет, така че да вървят на максимално множество от системи (SSE4 инструкция би изгърмяла на по-стар процесор примерно) и тези оптимизации там съответно ги няма.

Друг е въпроса че файдата от всичко това е маргинална, освен обикновено в разни частни/гранични случаи или при високо натоварване. А и работата, която ядрото извършва е предимно I/O-интензивна, а не CPU-интензивна така или иначе.

Същото е и с изключването на разни подсистеми и модули - в частни случаи може да спести доста процесорни тактове, в общият случай няма особено значение. За десктоп система за общо ползване, обикновено няма никакво значение.

P.S за да изпреваря въпроса "дай ми пример", простият банален пример е с conntracking-а в ядрото, който в общи линии ти дава възможността да си правиш NAT и/или stateful firewall там с iptables. Като го изключиш, печелиш одма поне едни 50% по-ниска латентност при обслужването и рутирането на всеки TCP пакет просто защото не ходи да рови в разни таблици, които може да са в процесорния кеш, може да не са, ако не са, хабиш стотици процесорни тактове, докато се достави, а conntrack таблицата може да стане брутално голяма с времето и при подходящно натоварване. Ако просто ползваш машината за да браузваш и да гледаш видео в youtube, няма никакво значение. Ако я ползваш обаче като рутер, при прилично натоварване, машината ще се сгъне и ще откаже да търкаля повече трафик, отделно jitter-а ще е неприлично голям.

Обаче айде това не е добър пример, защото може да се билдне като като модул и при добро желание може да го разкараш. Но все още има прилично много неща, които не стават точно така.


Bottom line: повечето хора които прекомпилират ядра и твърдят че вървят по-бързо, обикновено не могат да дефинират кое точно е по-бързо. Чисто теоретично е по-бързо и в определени случаи това "по-бързо" може да е с порядъци. Userland-а е достатъчно сложен, начините на ползването му - също. Може това дето да е по-бързо да е абсолютно ирелевантно, примерно да речем като отвориш видео в някой плеър оттам до възпроизвеждането да минат 50 вместо 200 милисекунди и аха изглежда като подобрение, обаче на човек изначално му е трудно да идентифицира кое точно му изглежда по-бързо.

Те затова такива спорове са тъпи, първо защото не може да се конкретизира върху конкретен проблем и второ, дори това да е налице, profile-ването на цялата работа е достатъчно досадно занимание, а пък точно оттам евентуално ще дойдат твърдите "числа" дето да докажат нещо.

Това казано, за x86 не съм ползвал прекомпилирани ядра от сигурно едно 10 години, просто защото не виждам нужда. За ARM признавам сме билдвали custom ядра, но на старата работа, не за мои си неща. Компилирането на ядра е ужасно досадна работа, аз сигурно съм прост обаче не ми се получава добре от първия път, обикновено не и от втория и третия, евентуално след един месец се сещам поради някаква причина че не ми се е получило пак и отново, часове потрошено процесорно време и електроенергия, майката природа не се кефи на такъв зъл carbon footprint нали така.

Съгласен, тук има и друга такава тема отскоро, макар и не точно в същия дух, обаче ми се струва разумно преди да се задава въпроса "как", да имаме отговор на "какво". Нещата са достатъчно комплексни, за да няма прост отговор, вярно е хиперболизиране в случая, но да речем сравнението е "ще правя завод, как?". Очевидно има значение какво ще произвежда този завод най-малкото.

Тъй като обикновено става въпрос малко или много за съвсем реални парични разходи, с цел най-малкото да се оптимизират нещата е редно да се знае какво ще върви, къде са му bottleneck-ите, какво натоварване се очаква. Примерно представи си три различни случая: vbox7.com, flightradar24.com и slack.com, едното е видео стрийминг услуга, другото онлайн система за проследяване на полети, третото е натоварен уеб-базиран чат.

На vbox7.com изискванията към мрежов/IO bandwidth са високи, понеже видеата малко или много са "обемни" като информация. В този случай да - dual gigabit картите сложени в bonding интерфейс и по възможност вързани не към един, а към два различни суича (в случай че суичовете са "умни"), имат повече смисъл. Също RAID 10 масив от много дискове ще ти осигури високия дисков bandwidth и надеждност на съответната цена.

На flightradar24.com нещата са други, там изискванията са към процесорно време. Стотици, вероятно хиляди пичове feed-ват на живо ADS-B информация и онези я предоставят на потребителите в реално време. Огромната част от процесинга се прави в клиентския браузър и всичко са json заявки, но сървърът им трябва да сметна нещо важно - при дадения zoom level и център на картата колко и кои самолети се намират в момента с идеята да не изсипва периодично мегабайтите информация за всички полети по земното кълбо, това е безсмислено. Оттам се почват едни сметки, понеже картата е проекция, а GPS координатите са нещо съвсем различно от координати по картата, тези сметки сървърите ги правят за сума ти клиенти и основното изискване (без да работя там, просто е лесно да си го представя) - е откъм изчислителна мощност и донякъде и латентност. Оттам, може би bonding интерфейсите и големите RAID10 масиви не са толкова важни, колкото осигуряването на достатъчно изчислителна мощност, правилното балансиране на заявките към сървърите така че да няма много по-натоварени и такива, които спят, такива работи.

На slack.com пък акцентът е върху надеждността и латентността, хората трябва възможно най-бързо да си виждат чат съобщенията, но и да си виждат и историята на чатовете, има масивно огромен брой клиенти, които нон-стоп poll-ват сървърите и там надеждността и латентността е цар. Налага се наличието на кеширащ слой отгоре на базата, а това пък налага повечко физическа памет на машините. Това измества и изискванията към storage-а, там дисковете е по-добре да са организирани в масиви, за които надеждността е най-важният фактор, което измества нещата накъм RAID5 масиви с parity. Защо не и SSD дискове с оглед на минимизиране на латентността на някои операции. Защо не някой хардуерен load-balancer, особено ако може да терминира TLS връзки, който да осигурява минимална латентност.

Всичко това предопределя и софтуерът, който ще се ползва. В смисъл защо да си слагаме каручката пред коня в крайна сметка, важно е да се знае каква е крайната идея и къде са проблемите.

Това е waterfall картинка, софтуер всякакъв има дето го прави това. Дори на питон можеш да си го напишеш, аз съм си играл навремето - требе ти само някоя хубава FFT библиотека за да докараш входните данни от времевия в честотния домейн, както и някаква библиотека да чертае по екрана. Другото вече са някакви разкрасявания, за да изглежда по-красиво. Иначе мисля че с gqrx съм го правил, аз съм му фен отдавна.

Аз забравих че един пич беше споделил неговите опити отпреди години:

https://twitter.com/nono2357/status/690085162986643456

Има и презентация (на френски) и твърди че е разчитал от 15 метра RFID смарткарта. За жалост, не разбирам френски