- Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 2/2] es18xx: remove snd_audiodrive structure
by Krzysztof Helt 25 Oct '09

25 Oct '09

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> Remove intermediate snd_audiodrive structure between snd_card structure and snd_es18xx. This reduces size of source code and binary driver. Signed-off-by: Krzysztof Helt <krzysztof.h1(a)wp.pl> --- sound/isa/es18xx.c | 71 ++++++++++++++++++--------------------------------- 1 files changed, 25 insertions(+), 46 deletions(-) diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c index 160752b..5cf42b4 100644 --- a/sound/isa/es18xx.c +++ b/sound/isa/es18xx.c @@ -139,10 +139,6 @@ struct snd_es18xx { #ifdef CONFIG_PM unsigned char pm_reg; #endif -}; - -struct snd_audiodrive { - struct snd_es18xx *chip; #ifdef CONFIG_PNP struct pnp_dev *dev; struct pnp_dev *devc; @@ -755,8 +751,7 @@ static int snd_es18xx_playback_trigger(struct snd_pcm_substream *substream, static irqreturn_t snd_es18xx_interrupt(int irq, void *dev_id) { struct snd_card *card = dev_id; - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; unsigned char status; if (chip->caps & ES18XX_CONTROL) { @@ -1699,8 +1694,7 @@ static struct snd_pcm_ops snd_es18xx_capture_ops = { static int __devinit snd_es18xx_pcm(struct snd_card *card, int device, struct snd_pcm **rpcm) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; struct snd_pcm *pcm; char str[16]; int err; @@ -1742,8 +1736,7 @@ static int __devinit snd_es18xx_pcm(struct snd_card *card, int device, #ifdef CONFIG_PM static int snd_es18xx_suspend(struct snd_card *card, pm_message_t state) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); @@ -1760,8 +1753,7 @@ static int snd_es18xx_suspend(struct snd_card *card, pm_message_t state) static int snd_es18xx_resume(struct snd_card *card) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; /* restore PM register, we won't wake till (not 0x07) i/o activity though */ snd_es18xx_write(chip, ES18XX_PM, chip->pm_reg ^= ES18XX_PM_FM); @@ -1773,8 +1765,7 @@ static int snd_es18xx_resume(struct snd_card *card) static int snd_es18xx_free(struct snd_card *card) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; release_and_free_resource(chip->res_port); release_and_free_resource(chip->res_ctrl_port); @@ -1789,7 +1780,6 @@ static int snd_es18xx_free(struct snd_card *card) disable_dma(chip->dma2); free_dma(chip->dma2); } - kfree(chip); return 0; } @@ -1802,19 +1792,14 @@ static int __devinit snd_es18xx_new_device(struct snd_card *card, unsigned long port, unsigned long mpu_port, unsigned long fm_port, - int irq, int dma1, int dma2, - struct snd_es18xx ** rchip) + int irq, int dma1, int dma2) { - struct snd_es18xx *chip; + struct snd_es18xx *chip = card->private_data; static struct snd_device_ops ops = { .dev_free = snd_es18xx_dev_free, }; int err; - *rchip = NULL; - chip = kzalloc(sizeof(*chip), GFP_KERNEL); - if (chip == NULL) - return -ENOMEM; spin_lock_init(&chip->reg_lock); spin_lock_init(&chip->mixer_lock); spin_lock_init(&chip->ctrl_lock); @@ -1865,14 +1850,12 @@ static int __devinit snd_es18xx_new_device(struct snd_card *card, snd_es18xx_free(card); return err; } - *rchip = chip; return 0; } static int __devinit snd_es18xx_mixer(struct snd_card *card) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; int err; unsigned int idx; @@ -2074,11 +2057,11 @@ static int __devinit snd_audiodrive_pnp_init_main(int dev, struct pnp_dev *pdev) return 0; } -static int __devinit snd_audiodrive_pnp(int dev, struct snd_audiodrive *acard, +static int __devinit snd_audiodrive_pnp(int dev, struct snd_es18xx *chip, struct pnp_dev *pdev) { - acard->dev = pdev; - if (snd_audiodrive_pnp_init_main(dev, acard->dev) < 0) + chip->dev = pdev; + if (snd_audiodrive_pnp_init_main(dev, chip->dev) < 0) return -EBUSY; return 0; } @@ -2104,26 +2087,26 @@ static struct pnp_card_device_id snd_audiodrive_pnpids[] = { MODULE_DEVICE_TABLE(pnp_card, snd_audiodrive_pnpids); -static int __devinit snd_audiodrive_pnpc(int dev, struct snd_audiodrive *acard, +static int __devinit snd_audiodrive_pnpc(int dev, struct snd_es18xx *chip, struct pnp_card_link *card, const struct pnp_card_device_id *id) { - acard->dev = pnp_request_card_device(card, id->devs[0].id, NULL); - if (acard->dev == NULL) + chip->dev = pnp_request_card_device(card, id->devs[0].id, NULL); + if (chip->dev == NULL) return -EBUSY; - acard->devc = pnp_request_card_device(card, id->devs[1].id, NULL); - if (acard->devc == NULL) + chip->devc = pnp_request_card_device(card, id->devs[1].id, NULL); + if (chip->devc == NULL) return -EBUSY; /* Control port initialization */ - if (pnp_activate_dev(acard->devc) < 0) { + if (pnp_activate_dev(chip->devc) < 0) { snd_printk(KERN_ERR PFX "PnP control configure failure (out of resources?)\n"); return -EAGAIN; } snd_printdd("pnp: port=0x%llx\n", - (unsigned long long)pnp_port_start(acard->devc, 0)); - if (snd_audiodrive_pnp_init_main(dev, acard->dev) < 0) + (unsigned long long)pnp_port_start(chip->devc, 0)); + if (snd_audiodrive_pnp_init_main(dev, chip->dev) < 0) return -EBUSY; return 0; @@ -2139,24 +2122,20 @@ static int __devinit snd_audiodrive_pnpc(int dev, struct snd_audiodrive *acard, static int snd_es18xx_card_new(int dev, struct snd_card **cardp) { return snd_card_create(index[dev], id[dev], THIS_MODULE, - sizeof(struct snd_audiodrive), cardp); + sizeof(struct snd_es18xx), cardp); } static int __devinit snd_audiodrive_probe(struct snd_card *card, int dev) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip; + struct snd_es18xx *chip = card->private_data; struct snd_opl3 *opl3; int err; - if ((err = snd_es18xx_new_device(card, - port[dev], - mpu_port[dev], - fm_port[dev], - irq[dev], dma1[dev], dma2[dev], - &chip)) < 0) + err = snd_es18xx_new_device(card, + port[dev], mpu_port[dev], fm_port[dev], + irq[dev], dma1[dev], dma2[dev]); + if (err < 0) return err; - acard->chip = chip; sprintf(card->driver, "ES%x", chip->version); -- 1.6.0.3 ---------------------------------------------------------------------- Nie dla nich ciepla praca za biurkiem. Sprawdz >>> http://link.interia.pl/f2383

1 0

[alsa-devel] Problems in snd_device_name_hint
by John Lindgren 25 Oct '09

25 Oct '09

Hello, I haven't frequented the alsa-devel list in the past, but Debian's maintainer apparently prefers that I go directly to the ALSA developers. While developing a new ALSA output plugin for Audacious audio player, I have run into several problems in snd_device_name_hint. I've already described the problems in the Debian bug tracker and made up some patches, which I would like someone to review. Here are the links: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549531 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552240 I'm also attaching the patches here. Peace, John Lindgren

1 0

Re: [alsa-devel] How to close ALSA device nodes?
by Rémi Denis-Courmont 24 Oct '09

24 Oct '09

Le dimanche 18 octobre 2009 20:13:15 Robert Hancock, vous avez écrit : > > From the earlier thread, I reckon that ALSA developers consider that this > > is an upper-layer issue. Maybe so, but then how is the upper-layer > > supposed to find which file descriptors ALSA-lib has opened - if any? > > Conversely, if ALSA- lib won't tell while file descriptors it is using, > > what could possibly be the use case for not closing those on exec? > > I agree that it's a difficult problem for an app that wants to fork > and exec another process.. I'd think really should be some way for an > app to control the CLOEXEC flag for the file descriptors that alsa-lib > has open.. Right. The kernel recently introduced the O_CLOEXEC open flag, to support thread-safe close-on-exec. The only way to leverage this is for ALSA-lib to set close-on-exec itself when it opens a file (whether by default or when the application requests it). That said, I still fail to see any potential use case to not set the flag. Since ALSA-lib won't let the application know about the file handles, any application cannot a use them across exec() in the first place. For the reference, glibc is now setting close-on-exec in similar cases, e.g. syslog(). > I guess the alternative would be to shutdown all open PCMs, etc. in > ALSA in the child process after forking and before the exec, so that > they don't end up still open for the new process.. I suspect such an approach would be painful both for ALSA and for the applications. From ALSA, this would need safety with regards to fork in another thread. That probably requires pthread_atfork() *glurp* if ALSA is to keep its SMP & thread-safety promise *ouch*. From the application, this require calling an ALSA function between fork and exec. That would forbid using system(), popen() or -faster- posix_spawn*(). That also means linking to ALSA in every place that executes. Considering that VLC is heavily plugin- based, this would be so impractical that I'd even rather scan through /proc/self/fd... -- Rémi Denis-Courmont http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary

2 5

[alsa-devel] What is the meaning of the mask values in the pcm hw constraints struct ?
by Neil Jones 24 Oct '09

24 Oct '09

I am developing an ASoC driver for a custom SoC (not in tree yet), I have written the platform and board modules and my hardware detects and installs ok, im now trying to play sound using aplay but im having issues. I get the error "aplay: set_params:1022: Unable to install hw params:" I have traced the problem to a failing ioctl call (snd_pcm_playback_ioctl) the error occurs in snd_pcm_hw_refine when refining the mask for the SNDRV_PCM_HW_PARAM_ACCESS mask, all the bit fields in my runtime->hw_constraints are zero for this field, but the requested params have the value 7, Im not sure what this means, the SNDRV_PCM_ACCESS_xxx defines in asound.h only go upto 4 ? I have attached logs below (with RULES_DEBUG turned on) hopefully this may shed some light. Thanks in advance for any help, Neil Jones Logs: # /usr/bin/aplay /var/snd48khz.wav Playing WAVE '/var/snd48khz.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo aplay: set_params:1022: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (85333 85334) PERIOD_SIZE: 4096 PERIOD_BYTES: 16384 PERIODS: (5 6) BUFFER_TIME: 500000 BUFFER_SIZE: 24000 BUFFER_BYTES: 96000 TICK_TIME: 0 (klog) ... Rule 0 [4030f9f4]: FORMAT = 4 -> 4 Rule 2 [4030f750]: SAMPLE_BITS = [16 16] -> [16 16] Rule 4 [4030f90c]: FRAME_BITS = [16 16] -> [16 16] Rule 5 [4030f90c]: FRAME_BITS = [16 16] -> [16 16] Rule 7 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 8 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 9 [4030f750]: PERIODS = [1 128] -> [1 128] Rule 10 [4030f750]: PERIOD_SIZE = [16 4096] -> [16 4096] Rule 12 [4030f828]: PERIOD_SIZE = [16 4096] -> [16 4096] Rule 15 [4030f828]: BUFFER_SIZE = [16 65536] -> [16 65536] Rule 18 [4030f90c]: PERIOD_TIME = (166 128000] -> (333 85334) Rule 19 [4030f90c]: BUFFER_TIME = (166 2048000] -> (333 1365334) Rule 7 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 8 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 12 [4030f828]: PERIOD_SIZE = [16 4096] -> [16 4096] Rule 15 [4030f828]: BUFFER_SIZE = [16 65536] -> [16 65536] ACCESS = 0000000000000007 -> 0000000000000000 - This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm Imagination Technologies Ltd is a limited company registered in England No: 1306335 Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ. Email to and from the company may be monitored for compliance and other administrative purposes. -

2 3

[alsa-devel] libasound2: snd_device_name_hint() wrongly calls snd_config_delete()
by Elimar Riesebieter 23 Oct '09

23 Oct '09

forwarded 549531 alsa-devel(a)alsa-project.org thanks This looks more like a general problem and shouldn't be solved distribution specific so request for help to the alsa developers. Elimar * John Lindgren [091003 20:34 -0400] > Package: libasound2 > Version: 1.0.21a-1 > Severity: normal > Tags: patch > > Symptoms > -------- > > This bug first showed up because of a new ALSA output plugin for > Audacious audio player: > > http://jira.atheme.org/browse/AUDPLUG-77#action_10640 > > Essentially, any call to snd_device_name_hint() causes later calls to > snd_pcm_open() to fail with messages like these: > > ALSA lib conf.c:4600:(snd_config_expand) Unknown parameters CARD=Live,DEV=0 > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM rear:CARD=Live,DEV=0 > > This happens only for PCMs defined in ALSA config files (such as the > ones under /usr/share/alsa/cards), not for "default" or "hw:0,0"-style. > It does not seem to depend on a particular sound card. It can be > reproduced without Audacious by adding a call to pcm_list() before the > call to snd_pcm_open() in aplay.c from the alsa-utils package: > > $ ./aplay -D front:CARD=ICH6,DEV=0 Test.wav > default:CARD=ICH6 > Intel ICH6, Intel ICH6 > Default Audio Device > front:CARD=ICH6,DEV=0 > Intel ICH6, Intel ICH6 > Front speakers > surround40:CARD=ICH6,DEV=0 > Intel ICH6, Intel ICH6 > 4.0 Surround output to Front and Rear speakers > surround41:CARD=ICH6,DEV=0 > Intel ICH6, Intel ICH6 > 4.1 Surround output to Front, Rear and Subwoofer speakers > surround50:CARD=ICH6,DEV=0 > Intel ICH6, Intel ICH6 > 5.0 Surround output to Front, Center and Rear speakers > surround51:CARD=ICH6,DEV=0 > Intel ICH6, Intel ICH6 > 5.1 Surround output to Front, Center, Rear and Subwoofer speakers > iec958:CARD=ICH6,DEV=0 > Intel ICH6, Intel ICH6 - IEC958 > IEC958 (S/PDIF) Digital Audio Output > null > Discard all samples (playback) or generate zero samples (capture) > ALSA lib conf.c:4600:(snd_config_expand) Unknown parameters CARD=ICH6,DEV=0 > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM front:CARD=ICH6,DEV=0 > aplay: main:610: audio open error: Invalid argument > > Diagnosis > --------- > > try_config(), called by snd_device_name_hint(), calls > snd_config_search_definition() at namehint.c line 243 and > snd_config_search_alias_hooks() at line 339, then calls > snd_config_delete() on the returned nodes at lines 331 and 383. This > was probably meant to prevent leaking memory returned by the search > functions, but in fact it removes information from the config that is > needed by later calls, such as snd_pcm_open. Hence, snd_pcm_open > behaves as though devices like "front" and "rear" do not exist. > > I have attached a patch for aplay.c to reproduce the problem and a patch > for namehint.c to fix it. One side effect of the fix (on my system at > least) is that two "null" devices are now listed by "aplay -L" and in > Audacious. > > Peace, > John Lindgren > > > -- System Information: > Debian Release: squeeze/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: i386 (i686) > > Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages libasound2 depends on: > ii libc6 2.9-25 GNU C Library: Shared libraries > > libasound2 recommends no packages. > > Versions of packages libasound2 suggests: > pn libasound2-plugins <none> (no description available) > > -- no debconf information > --- aplay.0.c 2009-08-31 11:13:36.000000000 -0400 > +++ aplay.c 2009-10-03 19:54:43.000000000 -0400 > @@ -603,6 +603,8 @@ > goto __end; > } > > + pcm_list(); > + > err = snd_pcm_open(&handle, pcm_name, stream, open_mode); > if (err < 0) { > error(_("audio open error: %s"), snd_strerror(err)); > --- namehint.0.c 2009-09-09 08:34:54.000000000 -0400 > +++ namehint.c 2009-10-03 17:39:23.000000000 -0400 > @@ -328,7 +328,6 @@ > if (snd_config_search(cfg1, "slave", &cfg) >= 0 && > snd_config_search(cfg, base, &cfg1) >= 0) > goto __hint; > - snd_config_delete(res); > res = NULL; > if (strchr(buf, ':') != NULL) > goto __ok; > @@ -379,8 +378,6 @@ > err = hint_list_add(list, buf, buf1); > } > __skip_add: > - if (res) > - snd_config_delete(res); > if (buf1) > free(buf1); > free(buf); > _______________________________________________ > Pkg-alsa-devel mailing list > Pkg-alsa-devel(a)lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/pkg-alsa-devel -- It's a good thing we don't get all the government we pay for.

1 0

[alsa-devel] Exemple of source code for capture without using callback
by brunal2496 gmail 23 Oct '09

23 Oct '09

Hi all, it's my first time on this list and my knowledge about using poll() mutex and thread creation is a bit far away from now, so please, if this list is the wrong place for such a question, could you point me in the right direction? Does anyone can point me a place to find a good exemple of source code for capturing sound with alsa without using callbacks? I'm trying to interface a voice recognition software with the alsa drivers. I have to get audio from alsa convert it and then send to the recognition engine. I've read everywhere that using callback is a bad method to use the alsa drivers. As the recognition software is a server, it needs to be synchronized with my application. And so my main() cannot loop on a endless loop with the snd_pcm_readi() function inside. My first idea was to create a new thread and to let this thread running with a endless loop that do the snd_pcm_readi() and send the buffer to the recognition software. But I 've read the existence of smd_pcm_poll_descriptors() function. For now I not shure was it is for and how to use it properly. What do you think? I'm sorry if my question is a real newbie question, but exemple online are only for playback not capture. Many thanks for all your answers. Bruno.

3 4

[alsa-devel] Developing and cross-compiling an ASoC driver
by Szabolcs Erki 22 Oct '09

22 Oct '09

Hello, I recently designed a custom board based on an AT91SAM9 microcontroller connected with an ADC via I2S. In the project we need a data acquisition application, which can store audio stream to wav files. On my opinion arecord fulfills our requirements. The "only" thing we have to do is writing an ASoC driver especially for the ADC (ADS1274), and cross compile it to the Linux4SAM embedded Linux environment. I didn't find any suitable description how to do a cross-platform driver development process. Could you please give me some introduction how to: - cross compile alsa-driver (AFAIK ASoC is part of it, and ALSA is part of the linux kernel), and alsa-utils (for getting arecord) - cross compile the newly developed alsa driver - integrate ASoC and the custom driver to the patched kernel (Linux4SAM) and cross compile them to one image. Thank you for your help in advance! Br, Szabolcs Erki

2 4

[alsa-devel] [PATCH alsa-lib 1/3] Open device nodes with close-on-exec flag
by Rémi Denis-Courmont 22 Oct '09

22 Oct '09

From: Rémi Denis-Courmont <remi(a)remlab.net> This avoid leaking device descriptors through exec. Thus ALSA applications can safely spawn other processes in their background. Signed-off-by: Rémi Denis-Courmont <remi(a)remlab.net> --- include/local.h | 23 +++++++++++++++++------ 1 files changed, 17 insertions(+), 6 deletions(-) diff --git a/include/local.h b/include/local.h index b5a1c45..5b54def 100644 --- a/include/local.h +++ b/include/local.h @@ -230,22 +230,33 @@ extern snd_lib_error_handler_t snd_err_msg; # define link_warning(symbol, msg) #endif -/* open with resmgr */ -#ifdef SUPPORT_RESMGR static inline int snd_open_device(const char *filename, int fmode) { - int fd = open(filename, fmode); + int fd; + +#ifdef O_CLOEXEC + fd = open(filename, fmode|O_CLOEXEC); if (fd >= 0) return fd; + if (errno == EINVAL) +#endif + { + fd = open(filename, fmode); + if (fd >= 0) { + fcntl(fd, F_SETFD, FD_CLOEXEC); + return fd; + } + } + +/* open with resmgr */ +#ifdef SUPPORT_RESMGR if (errno == EAGAIN || errno == EBUSY) return fd; if (! access(filename, F_OK)) return rsm_open_device(filename, fmode); +#endif return -1; } -#else -#define snd_open_device(filename, fmode) open(filename, fmode); -#endif /* make local functions really local */ #define snd_dlobj_cache_lookup \ -- 1.6.5

1 2

[alsa-devel] [PATCH alsa-lib 1/3] Open device nodes with close-on-exec flag
by Rémi Denis-Courmont 22 Oct '09

22 Oct '09

This avoid leaking device descriptors through exec. Thus ALSA applications can safely spawn other processes in their background. Signed-off-by: Rémi Denis-Courmont <remi(a)remlab.net> --- include/local.h | 23 +++++++++++++++++------ 1 files changed, 17 insertions(+), 6 deletions(-) diff --git a/include/local.h b/include/local.h index b5a1c45..5b54def 100644 --- a/include/local.h +++ b/include/local.h @@ -230,22 +230,33 @@ extern snd_lib_error_handler_t snd_err_msg; # define link_warning(symbol, msg) #endif -/* open with resmgr */ -#ifdef SUPPORT_RESMGR static inline int snd_open_device(const char *filename, int fmode) { - int fd = open(filename, fmode); + int fd; + +#ifdef O_CLOEXEC + fd = open(filename, fmode|O_CLOEXEC); if (fd >= 0) return fd; + if (errno == EINVAL) +#endif + { + fd = open(filename, fmode); + if (fd >= 0) { + fcntl(fd, F_SETFD, FD_CLOEXEC); + return fd; + } + } + +/* open with resmgr */ +#ifdef SUPPORT_RESMGR if (errno == EAGAIN || errno == EBUSY) return fd; if (! access(filename, F_OK)) return rsm_open_device(filename, fmode); +#endif return -1; } -#else -#define snd_open_device(filename, fmode) open(filename, fmode); -#endif /* make local functions really local */ #define snd_dlobj_cache_lookup \ -- 1.6.5

1 2

[alsa-devel] patchmix application for EMU1616m
by Dominik Zalewski 22 Oct '09

22 Oct '09

Is there anybody working on patchmix application for alsa? I'm wondering what would be the guidelines. - Should it be a clone of a patchmix for Windows: a separate program? - Or maybe there is already some infrastructure in Alsa that should be extended with that functionality? - Alsamixer already has some of that functionality, should be replicated in new patchmix application? - Are there any restrictions for the GUI libraries that may be used? - Does it have to be written in C/C++, or is Java also applicable? -- Dominik Zalewski

2 1