Problem z /dev/esd

[soku11]

Witam.
Mam pewien problem. Napisałem prostą aplikację cross-platform do odtwarzania plików mp3. Pod systemami windows jest wszystko ok. Natomiast pod fedorą (taki mam OS) przy próbie stworzenia urządzenia do odtwarzania dostaję taki komunikat:

/dev/dsp: Device or resource busy

Czytałem, że z tego urządzenia może korzystać tylko jeden proces jednocześnie (nie ma możliwości miksowania). No niby ok, tylko że ja niczego w tle grającego nie mam :/ Czy da się sprawdzić co dokładnie blokuje mi to urządzenie oraz jakoś to wyłączyć?

Pozdrawiam.

[arctgx]

Zobacz manuale lsof i fuser.

[soku11]

Po fuser /dev/dsp nie dostaję nic.
lsof /dev wyświetla mi mnóstwo null, urandom, console, etc. Z dźwiękiem związane jest tylko snd/controlC0...

Nie mam pojęcia co z tym jest :/ Czytałem, że ten system OSS pozwala tylko jednemu procesowi na korzystanie z urządzenia. I tak się składa, że innego poza mną nie ma. Logowanie na roota nic nie zmienia.


I jeszcze ciekawa sprawa. Użyłem teraz dekodera z biblioteki libmpg123. Myślałem, że dekoder, to tylko software'owy programik i będzie śmigać. Co się okazało - tam się pojawia błąd z Brakiem dostępu (po polsku - inny komunikat) do /dev/snd/pcmCXDX. Coprawda zalogowanie się na roota załatwia sprawę, jednak wydaje mi się to bardzo dziwne i głupie. W końcu jak ktoś chce sobie włączyć odtwarzacz muzyki nie musi być rootem :/

Ktoś wie o co w tym chodzi?

Pozdrawiam.

[arctgx]

Po fuser /dev/dsp nie dostaję nic.
lsof /dev wyświetla mi mnóstwo null, urandom, console, etc. Z dźwiękiem związane jest tylko snd/controlC0...

Nie mam pojęcia co z tym jest :/ Czytałem, że ten system OSS pozwala tylko jednemu procesowi na korzystanie z urządzenia. I tak się składa, że innego poza mną nie ma. Logowanie na roota nic nie zmienia.


I jeszcze ciekawa sprawa. Użyłem teraz dekodera z biblioteki libmpg123. Myślałem, że dekoder, to tylko software'owy programik i będzie śmigać. Co się okazało - tam się pojawia błąd z Brakiem dostępu (po polsku - inny komunikat) do /dev/snd/pcmCXDX. Coprawda zalogowanie się na roota załatwia sprawę, jednak wydaje mi się to bardzo dziwne i głupie. W końcu jak ktoś chce sobie włączyć odtwarzacz muzyki nie musi być rootem :/

Nie mam nic wspólnego z programowaniem aplikacji linuksowych, ale mam wrażenie, że rzuciłeś się do napisania programu, nie znając kilku podstaw związanych ze zwykłym używaniem systemu.

Właścicielem plików urządzeń dźwiękowych jest root, ale grupą jest zazwyczaj audio (man ls, man stat). Być może wystarczy dodać użytkownika do grupy audio (man id, man adduser), by miał tam prawa do odczytu lub zapisu.

Druga sprawa, co do której nie jestem pewien, ale zapytam bo też wydaje mi się podejrzana: program ma korzytać z podsystemu OSS czy ALSA (obsługuje emulację archaicznego OSS)? Pliki typu pcmCXDX zdają się być tworami Alsy (niech mnie ktoś poprawi). Jeśli piszesz pod Alsę, poszukaj na jej wiki o programowym miksowaniu (dmix) - to bardziej dla użytkownika niż twórcy. Zaglądałeś do katalogu sound w dokumentacji jądra dołączanej do źródeł?

Trzecia: szukasz w końcu procesu używającego /dev czy /dev/coś_tam?

Czwarta: rozróżniasz pojęcie procesu od użytkownika ("OSS pozwala tylko jednemu procesowi na korzystanie z urządzenia. I tak się składa, że innego poza mną nie ma")?

[soku11]

W gruncie rzeczy aż tak duża wiedza nie jest potrzebna. Po to są biblioteki, by nie zagłębiać się w szczegóły implementacji i działania.

Wiem, że właścicielem plików dźwiękowych jest root. Spróbuję później dodać sobie prawa do tej grupy. Jednak nie wydaje mi się, żebym coś takiego robił instalując sobie np. Amaroka...

Na początku korzystałem z biblioteki audiere, która korzysta z OSS. Później przy problemach doczytałem, że lepiej użyć nowszej ALSY. Co prawda znalazłem nową wersję audiere korzystającą z ALSY, jednak nie za bardzo się ona nadaje. Dlatego postanowiłem najpierw napisać dekoder mp3 do postaci dźwięku bez kompresji, a później użyć jakiejś biblioteki do odegrania tego. Nie zamierzam bawić się w pisanie samemu odgrywania dźwięków przez ALSĘ, gdyż istnieją do tego biblioteki. Do katalogu sound później zajrzę. Pytanie tylko po co...

Szukałem /dev/dsp i w obu przypadkach nic nie znalazłem. Później szukałem samego /dev by ogólnie zobaczyć co z czego korzysta.

To był taki skrót myślowy. Wiem co to proces i wiem co to użytkownik. Chodziło mi o to, że nie ma żadnego procesu (sądząc po lsof i fuser) korzystającego w danej chwili z /dev/dsp. Tylko mój programik próbując się uruchomić próbuje uzyskać do niego dostęp

Pozdrawiam.

[arctgx]

Sprawdzenie czy dany użytkownik należy do grupy audio to rzecz jednorazowa, więc nie musisz zaprzątać sobie nią głowy przy kolejnych instalacjach. Swoją drogą, to chyba teraz rzadkość gdy nowy użytkownik nie jest domyślnie dopisany do tej grupy w momencie zakładania konta i trzeba ręcznie to uzupełniać.

Jeśli chodzi o dostęp do urządzenia dźwiękowego kilku procesów jednocześnie, przetestuj to na działających naraz odtwarzaczach (najprościej chyba przez aplay p1.wav & aplay p2.wav), konfigurując później ewentualnie wirtualne urządzenie miksujące.

[soku11]

Odtwarzacze oba naraz działają. Nie ma żadnego błędu. Co do tego pcmCXDX, to sprawa załatwiona. Okazało się, że coś wcześniej sprawdzałem i zapomniałem skasować przekierowywania

Polecenie id -g SOQ zwraca 500. Nie wiem jednak jak sprawdzić, czy jestem w grupie audio...

Pozdrawiam.

[arctgx]

Nie to "g" (patrz manual). Do sprawdzenia wcale nie potrzebujesz opcji: jako użytkownik klepnij po prostu id, chyba że sprawdzasz innego użytkownika, to jeszcze z jego nazwą odpal.

[soku11]

No to nic nie zmienia (zapomniałem napisać). Samo id wypluwa:
uid=500(SOQ) gid=500(SOQ) grupy=500(SOQ) context=unconfined_u:unconfined_r:unconfined_t:s0


W sumie już mam działającą metodę na odgrywanie mp3 (oddzielny dekoder i oddzielna bibloteka do odgrywania), jednak temat jak najbardziej aktualny. Ciekawi mnie skąd ten błąd dla OSS przy braku związanych z nim procesów...

Pozdrawiam.

[arctgx]

Dodaj więc adduserem użytkownika do audio, skoro w polu "grupy" jest tylko ta o GID=500. Zobacz też man group.

[Xax79]

Grupy do których należy użytkownik 'user' (będąc zalogowanym jako 'user')
#groups

Dodanie użytkownika 'user' do grupy 'grupa' (jako root)
#gpasswd -a user grupa

Zmiany widoczne są dopiero po powtórnym zalogowaniu użytkownika 'user'.

[soku11]

Przeglądając plik /etc/group nie widzę w ogóle grupy takiej jak audio... Jedyne o znalazłem, to grupa pulse-rt i pulse-access. Chociaż to nie wygląda na związane z oss :/ Jakieś inne pomysły?

Btw. Groups wyświetla mi tylko nazwę użytkownika (SOQ) i w pliku group też jest taka grupa. Trochę dziwne jak dla mnie...

Pozdrawiam.

[arctgx]

Używasz do tej zabawy Fedory z nagłówka własnych postów? Sposobem od podstaw może być sprawdzenie właścicieli i grup plików urządzeń dźwiękowych (np. ls -l /dev/dsp* /dev/snd).

U mnie za nadanie grupy audio urządzeniom dźwiękowym odpowiada reguła UDEV w pliku /lib/udev/rules.d/91-permissions.rules:

Kod: [Zaznacz]

SUBSYSTEM=="sound",                             GROUP="audio"

(pliki urządzeń są tworzone i usuwane dynamicznie przez UDEV, reguły mówią jak to robić). Jest to plik z debianowej paczki udev.  W paczce ze źródłami też znalazłem tę regułę w 40-alsa.rules. Nie wiem jak zorganizowano to w Fedorze.

[soku11]

Temat można zamknąć. Nie wiem czemu, ale taki komunikat dostaję TYLKO pod fedorą... Spróbowałem ubuntu, DSL, SLAX - wszędzie działa. Chyba porzucę tą dystrybucję i wybiorę inną bardziej stabilną i normalną

Pozdrawiam.