Technologie pro GUI nadstavbu nad alsou

Zdravím,

delší dobu uvažuji o GUI mixeru pro alsu. Stávající řešení (alsamixer, gnome mixer, mixer v KDE) jen nějakou heuristikou řadí ovládací prvky definované ovladačem zvukovky do skupin na záložky. Složitější karty definují desítky ovládacích prvků a žádná heuristika se nedokáže přiblížit specializovanému grafickému mixeru windowsího ovladače přímo od výrobce té které karty.

Je samozřejmě nesmysl pro každou kartu programovat vlastní GUI, jako je tomu ve windows. Ale věřím, že by se dal vytvořit univerzální nástroj, který by na vstupu vzal popisný konfigurák od autora ovladače (nebo jiného znalého dobrovolníka), který by popisoval jednak funkční závislosti ovládacích prvků, obsahoval detailní textový popis netriviálních "čudlíků", a zároveň do určité míry grafickému nástroji naznačoval, co jak vykreslit, aby to na první pohled dávalo smysl. Funkční závislosti ovl. prvků budou možná poskytovat přímo ovladače, to se již pomalu v konferenci alsy občas objevuje. Ale jejich smysluplné vykreslení do mixeru nikdo neřeší (alespoň o tom nevím).

Pulseaudio se snaží o zjednodušení sady ovl. prvků na základní a jejich umístění na GUI pulseaudia, ale mně jde o zpřístupnění všech čudlíků zvukovky (jako v GUI windowsích ovladačů od výrobce), tedy ještě v doméně alsy.

Tímto bych se chtěl zeptat, zda máte někdo zkušenosti s vhodnou grafickou knihovnou, která by bylo ideálně nezávislá na gnome/KDE/Xfce atd. a šla by snadno propojit s nějakým takovým konfigurákem. Možná by se hodil i nějaký skriptovaný jazyk (Python?), tato aplikace nevyžaduje žádný výpočetní výkon. Možná by i java dávala smysl. Pokud by ta knihovna podporovala i konzoli (ncurses?), o to lépe. Ale to není zásadní požadavek. Samozřejmě by to chtělo podporu lokalizace, i těch delších popisů čudlíků.

Jsem ve fázi přemýšlení, hledání možností, do alsí konference bych rád přišel již s představou něčeho konkrétnějšího. Díky moc za nápady, návrhy, doporučení.

Odpovědi

Sice tématu ani trochu nerozumím, ale k zamyšlení: možná by bylo dobré, aby ten konfigurák byl přímo vykonatelný skript volající nějaké jednoduché API, které navrhneš. Osobně dávám přednost Ruby, ale zdá se mi, že na podobné úlohy je Python v Linuxu prostě rozšířenější, a PyQt i PyGTK jsou už poměrně dobře "prověřené" knihovny (bindingy).

Zkus dát nějaký příklad, jak takový netriviální mixér vypadá, a můžeme se bavit, jak by měly ty konfiguráky/skripty vypadat. Zkusím ztvárnit svou naivní představu, která by s trochou snahy mohla být spustitelným kódem v Groovy (protože Python neumím a nevím, jestli v něm jde dělat tak hezké minijazyky).

group { // skupina ovládacích prvků, v GUI jako záložka?
  id "play"
  name "Přehrávání"
  // nebo ala gettext:
  name _("Přehrávání")

  control { // ovládací prvek
    id "mute0"
    name _("název")
    description _("popis")
    type "checkbox" // ovládací prvek je "zaškrtávátko"
    action { // kód, který se provede při změně stavu ovládacího prvku
      if (this.checked) { // this je aktuální ovládací prvek, tedy mute0
        soundCard.mute() //  zřejmě nějaké volání API Alsy
        controls["volume0"].disable()
      } else {
        soundCard.unmute() // 
        controls["volume0"].enable()
      }
    }
  }

  control {
    id "volume0"
    type "slider" // ovládací prvek je "táhlo"
    range 0, 100 // rozsah hodnot (má smysl pouze pro type slider)
    action {
      soundCard.setVolume(this.value) // opět this je "tento" ovládací prvek, tedy volume0
    }
  }
}

group {
  id "record"
  ...
}

Tohle funguje na základě takové drobné magie: group ,control, id, name, action atd. jsou vlastně všechno volání metod s danými parametry (které můžou a nemusí být uzavřeny v závorkách). Bloky { ... } jsou taky parametry – kusy kódu, které si lze uložit a kdykoli vykonat (u definičních metod se asi vykonají ihned, metoda action kód uchová a ten pak bude volán později při každé změně příslušného ovládacího prvku).

Volání metod vlastně v paměti vyrobí model mixéru, a ten pak můžeš vyrenderovat jak chceš. Vím, že v Ruby by to šlo velmi podobně, jak v Pythonu netuším.

No a protože zvukovým kartám vlastně vůbec nerozumím, tak to je ode mne asi tak všechno :-)

Ještě na tom nejsem tak špatně, abych četl Viewegha.

29.9.2009 17:11 dustin | skóre: 63 | blog: dustin
Rozbalit Rozbalit vše Re: Technologie pro GUI nadstavbu nad alsou

Díky moc, promyslím to a budu otravovat dále :)

Pulseaudio nemam rad, hlavne kvuli tomu ze porad jeste nefunguje spolehlive. Kazdopadne inteligentni razeni ovladacich prvku je jednim z cilu toho projektu. Autor pulseaudia spolupracuje s vyjojari ALSy a ALSA meni svoje API na zaklade pozadavku PulseAudio.

29.9.2009 14:51 dustin | skóre: 63 | blog: dustin
Rozbalit Rozbalit vše Re: Technologie pro GUI nadstavbu nad alsou

Pulseaudio chce zobrazovat zakladni sadu ovladacich prvku (jako napr. panel zvuku, soucast windows) a mapovat je na konkretni cudliky zvukovek. Zatim to resi pres nazvy a typy ovladacich prvku.

Mojim cilem je neco trochu jineho - zobrazit hezky a logicky vsechny ovladaci prvky karty, jako to dela GUI ovladace od vyrobce zvukovky. Umoznit i treba nejake logicke vazby mezi nimi (control 1 disabled if control 2 nema value 1, atd. - treba toto v driveru definovat nejde). Vyuziti na urovni stavajicich alsa mixeru (GUI i CLI), ale graficky a informacne tak, aby se v tom slo vyznat i bez studia zdrojaku driveru (nebo nejakeho popisu na wiki), coz byva dnes jedina moznost (jen popis na wiki stejne neni :) ).

pouzivam svuj jednoduchej mixer v openboxu jen na volume.

je napsany v pythonu s pomoci pygtk a pyalsaaudio.

myslim ze na tvoje potreby pyalsaaudio bude stacit

viz: alsaaudio.mixers()

29.9.2009 16:59 dustin | skóre: 63 | blog: dustin
Rozbalit Rozbalit vše Re: Technologie pro GUI nadstavbu nad alsou

Díky za tip, to vypadá celkem použitelně. Python neumím, ale údajně není tak složitý. Mrknu na to.

Dotaz: Technologie pro GUI nadstavbu nad alsou

Odpovědi