* double speed (ADAT), and hw params ordering @ 2002-07-18 18:58 Paul Davis 2002-07-19 10:40 ` Takashi Iwai 0 siblings, 1 reply; 8+ messages in thread From: Paul Davis @ 2002-07-18 18:58 UTC (permalink / raw) To: alsa-devel i've been wondering what to do about setting sample rates in the hammerfall and h-dsp drivers. fernando and gary from CCRMA have made the excellent suggestion that rather than have the driver pretend that all rates are available all the time, as it currently does, that we have a control switch to go between regular rates and the "double speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel count. i think this is an excellent idea. you would not be able to use the switch while the device was open. when you opened it, you would find (for example) a device with 14 channels (12 ADAT plus 2 SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz. if anyone objects to this model, please let me know. right now, its more or less impossible to get access to the higher rates. on a related note, although the above suggestion will fix this particular problem, it seems that it might be wise to consider adding a parameter order information field to the driver API, so that drivers can say "you have to set param P first, then param N, then param O". the default would obviously be "don't care", but for devices that lose certain capabilities when certain parameters are set, it would make things very much easier. --p ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: double speed (ADAT), and hw params ordering 2002-07-18 18:58 double speed (ADAT), and hw params ordering Paul Davis @ 2002-07-19 10:40 ` Takashi Iwai 2002-07-20 6:54 ` Jaroslav Kysela 2002-07-20 6:57 ` Jaroslav Kysela 0 siblings, 2 replies; 8+ messages in thread From: Takashi Iwai @ 2002-07-19 10:40 UTC (permalink / raw) To: Paul Davis; +Cc: alsa-devel At Thu, 18 Jul 2002 14:58:07 -0400, Paul Davis wrote: > > i've been wondering what to do about setting sample rates in the > hammerfall and h-dsp drivers. fernando and gary from CCRMA have made > the excellent suggestion that rather than have the driver pretend that > all rates are available all the time, as it currently does, that we > have a control switch to go between regular rates and the "double > speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel > count. i think this is an excellent idea. you would not be able to > use the switch while the device was open. when you opened it, you > would find (for example) a device with 14 channels (12 ADAT plus 2 > SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz. i vote for this idea. > if anyone objects to this model, please let me know. right now, its > more or less impossible to get access to the higher rates. > > on a related note, although the above suggestion will fix this > particular problem, it seems that it might be wise to consider adding > a parameter order information field to the driver API, so that drivers > can say "you have to set param P first, then param N, then param > O". the default would obviously be "don't care", but for devices that > lose certain capabilities when certain parameters are set, it would > make things very much easier. agreed that it's good to have such one. but how to implement this? from the design of hw_constraint, i don't think it's so easy... Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: double speed (ADAT), and hw params ordering 2002-07-19 10:40 ` Takashi Iwai @ 2002-07-20 6:54 ` Jaroslav Kysela 2002-07-20 6:57 ` Jaroslav Kysela 1 sibling, 0 replies; 8+ messages in thread From: Jaroslav Kysela @ 2002-07-20 6:54 UTC (permalink / raw) To: Takashi Iwai; +Cc: Paul Davis, alsa-devel On Fri, 19 Jul 2002, Takashi Iwai wrote: > At Thu, 18 Jul 2002 14:58:07 -0400, > Paul Davis wrote: > > > > i've been wondering what to do about setting sample rates in the > > hammerfall and h-dsp drivers. fernando and gary from CCRMA have made > > the excellent suggestion that rather than have the driver pretend that > > all rates are available all the time, as it currently does, that we > > have a control switch to go between regular rates and the "double > > speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel > > count. i think this is an excellent idea. you would not be able to > > use the switch while the device was open. when you opened it, you > > would find (for example) a device with 14 channels (12 ADAT plus 2 > > SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz. > > i vote for this idea. Paul, what's wrong to offer all possible configurations? Could > > if anyone objects to this model, please let me know. right now, its > > more or less impossible to get access to the higher rates. > > > > on a related note, although the above suggestion will fix this > > particular problem, it seems that it might be wise to consider adding > > a parameter order information field to the driver API, so that drivers > > can say "you have to set param P first, then param N, then param > > O". the default would obviously be "don't care", but for devices that > > lose certain capabilities when certain parameters are set, it would > > make things very much easier. > > agreed that it's good to have such one. > but how to implement this? > from the design of hw_constraint, i don't think it's so easy... > > > Takashi > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-devel > Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project http://www.alsa-project.org SuSE Linux http://www.suse.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: double speed (ADAT), and hw params ordering 2002-07-19 10:40 ` Takashi Iwai 2002-07-20 6:54 ` Jaroslav Kysela @ 2002-07-20 6:57 ` Jaroslav Kysela 2002-07-20 19:20 ` (no subject) Fernando Pablo Lopez-Lezcano 1 sibling, 1 reply; 8+ messages in thread From: Jaroslav Kysela @ 2002-07-20 6:57 UTC (permalink / raw) To: Takashi Iwai; +Cc: Paul Davis, alsa-devel On Fri, 19 Jul 2002, Takashi Iwai wrote: > At Thu, 18 Jul 2002 14:58:07 -0400, > Paul Davis wrote: > > > > i've been wondering what to do about setting sample rates in the > > hammerfall and h-dsp drivers. fernando and gary from CCRMA have made > > the excellent suggestion that rather than have the driver pretend that > > all rates are available all the time, as it currently does, that we > > have a control switch to go between regular rates and the "double > > speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel > > count. i think this is an excellent idea. you would not be able to > > use the switch while the device was open. when you opened it, you > > would find (for example) a device with 14 channels (12 ADAT plus 2 > > SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz. > > i vote for this idea. Paul, what's wrong to offer all possible configurations? Could you explain the problems? > > if anyone objects to this model, please let me know. right now, its > > more or less impossible to get access to the higher rates. > > > > on a related note, although the above suggestion will fix this > > particular problem, it seems that it might be wise to consider adding > > a parameter order information field to the driver API, so that drivers > > can say "you have to set param P first, then param N, then param > > O". the default would obviously be "don't care", but for devices that > > lose certain capabilities when certain parameters are set, it would > > make things very much easier. > > agreed that it's good to have such one. > but how to implement this? > from the design of hw_constraint, i don't think it's so easy... I think that this implementation will create a big mess for the application developers. Also, I'm not sure, if it's really needed, because our refining code should already reduce the available configurations. Applications should use *_near() functions in order of their priority. You can't predict, if rate or count of channels or any other parameter is more important for a specific application. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project http://www.alsa-project.org SuSE Linux http://www.suse.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
* (no subject) 2002-07-20 6:57 ` Jaroslav Kysela @ 2002-07-20 19:20 ` Fernando Pablo Lopez-Lezcano 2002-07-20 23:04 ` Abramo Bagnara ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Fernando Pablo Lopez-Lezcano @ 2002-07-20 19:20 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: Takashi Iwai, Gary Scavone, Paul Davis, alsa-devel > > > on a related note, although the above suggestion will fix this > > > particular problem, it seems that it might be wise to consider adding > > > a parameter order information field to the driver API, so that drivers > > > can say "you have to set param P first, then param N, then param > > > O". the default would obviously be "don't care", but for devices that > > > lose certain capabilities when certain parameters are set, it would > > > make things very much easier. > > > > agreed that it's good to have such one. > > but how to implement this? > > from the design of hw_constraint, i don't think it's so easy... > > I think that this implementation will create a big mess for the > application developers. Also, I'm not sure, if it's really needed, because > our refining code should already reduce the available configurations. > Applications should use *_near() functions in order of their priority. You > can't predict, if rate or count of channels or any other parameter is more > important for a specific application. [not exactly an answer but more details on what is actually happening] I think this is what is happening with the current driver (Gary, please correct me if I'm wrong): The application looks at the configuration space and selects from it one particular sampling rate. Then it looks at the channel count and sees a range of channel counts (10:18 - or some numbers like that, I don't remember). The application chooses the minimum channel count and the set function fails. IMHO at that point the configuration space should have changed the number of channels available to match the sampling rate selected so that the channel count as advertised is legal (ie: if the selected sampling rate is one of the "single speed" rates then the range of channels should be 18:18, if the sampling rate is one of the "double speed" rates then the range should be 10:10). The reverse is also true, if the application first selects number of channels the sampling rates should be constrained to the set of rates that can be supported by that number of channels. If it is not possible to do this with the current api, then the next best solution I can imagine is to have a switch that changes the mode of the card between single and double speed (that would make the dependency between sample rate and number of channels dissapear). -- Fernando ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (no subject) 2002-07-20 19:20 ` (no subject) Fernando Pablo Lopez-Lezcano @ 2002-07-20 23:04 ` Abramo Bagnara 2002-07-21 8:28 ` your mail Jaroslav Kysela 2002-07-21 18:56 ` hdsp channel/sample rate issues Gary Scavone 2 siblings, 0 replies; 8+ messages in thread From: Abramo Bagnara @ 2002-07-20 23:04 UTC (permalink / raw) To: Fernando Pablo Lopez-Lezcano Cc: Jaroslav Kysela, Takashi Iwai, Gary Scavone, Paul Davis, alsa-devel Fernando Pablo Lopez-Lezcano wrote: > > > > > on a related note, although the above suggestion will fix this > > > > particular problem, it seems that it might be wise to consider adding > > > > a parameter order information field to the driver API, so that drivers > > > > can say "you have to set param P first, then param N, then param > > > > O". the default would obviously be "don't care", but for devices that > > > > lose certain capabilities when certain parameters are set, it would > > > > make things very much easier. > > > > > > agreed that it's good to have such one. > > > but how to implement this? > > > from the design of hw_constraint, i don't think it's so easy... > > > > I think that this implementation will create a big mess for the > > application developers. Also, I'm not sure, if it's really needed, because > > our refining code should already reduce the available configurations. > > Applications should use *_near() functions in order of their priority. You > > can't predict, if rate or count of channels or any other parameter is more > > important for a specific application. > > [not exactly an answer but more details on what is actually happening] > > I think this is what is happening with the current driver (Gary, please > correct me if I'm wrong): The application looks at the configuration > space and selects from it one particular sampling rate. Then it looks at > the channel count and sees a range of channel counts (10:18 - or some > numbers like that, I don't remember). The application chooses the minimum > channel count and the set function fails. > > IMHO at that point the configuration space should have changed the number > of channels available to match the sampling rate selected so that the > channel count as advertised is legal (ie: if the selected sampling rate is > one of the "single speed" rates then the range of channels should be > 18:18, if the sampling rate is one of the "double speed" rates then the > range should be 10:10). > > The reverse is also true, if the application first selects number of > channels the sampling rates should be constrained to the set of rates that > can be supported by that number of channels. > > If it is not possible to do this with the current api, then the next best > solution I can imagine is to have a switch that changes the mode of the > card between single and double speed (that would make the dependency > between sample rate and number of channels dissapear). I've designed current refine API to do exactly what you've described. If this don't work for the specific card it's a card driver bug. -- Abramo Bagnara mailto:abramo.bagnara@libero.it Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: your mail 2002-07-20 19:20 ` (no subject) Fernando Pablo Lopez-Lezcano 2002-07-20 23:04 ` Abramo Bagnara @ 2002-07-21 8:28 ` Jaroslav Kysela 2002-07-21 18:56 ` hdsp channel/sample rate issues Gary Scavone 2 siblings, 0 replies; 8+ messages in thread From: Jaroslav Kysela @ 2002-07-21 8:28 UTC (permalink / raw) To: Fernando Pablo Lopez-Lezcano Cc: Takashi Iwai, Gary Scavone, Paul Davis, alsa-devel On Sat, 20 Jul 2002, Fernando Pablo Lopez-Lezcano wrote: > > > > on a related note, although the above suggestion will fix this > > > > particular problem, it seems that it might be wise to consider adding > > > > a parameter order information field to the driver API, so that drivers > > > > can say "you have to set param P first, then param N, then param > > > > O". the default would obviously be "don't care", but for devices that > > > > lose certain capabilities when certain parameters are set, it would > > > > make things very much easier. > > > > > > agreed that it's good to have such one. > > > but how to implement this? > > > from the design of hw_constraint, i don't think it's so easy... > > > > I think that this implementation will create a big mess for the > > application developers. Also, I'm not sure, if it's really needed, because > > our refining code should already reduce the available configurations. > > Applications should use *_near() functions in order of their priority. You > > can't predict, if rate or count of channels or any other parameter is more > > important for a specific application. > > [not exactly an answer but more details on what is actually happening] > > I think this is what is happening with the current driver (Gary, please > correct me if I'm wrong): The application looks at the configuration > space and selects from it one particular sampling rate. Then it looks at > the channel count and sees a range of channel counts (10:18 - or some > numbers like that, I don't remember). The application chooses the minimum > channel count and the set function fails. > > IMHO at that point the configuration space should have changed the number > of channels available to match the sampling rate selected so that the > channel count as advertised is legal (ie: if the selected sampling rate is > one of the "single speed" rates then the range of channels should be > 18:18, if the sampling rate is one of the "double speed" rates then the > range should be 10:10). > > The reverse is also true, if the application first selects number of > channels the sampling rates should be constrained to the set of rates that > can be supported by that number of channels. You've described exactly the behaviour which should be implemented in your paragraphs. If the current implementation is broken, then we should fix it. > If it is not possible to do this with the current api, then the next best > solution I can imagine is to have a switch that changes the mode of the > card between single and double speed (that would make the dependency > between sample rate and number of channels dissapear). You may look to snd_rme9652_hw_rule_channels(), snd_rme9652_hw_rule_channels_rate() and snd_rme9652_hw_rule_rate_channels() functions in rme9652.c. These functions exactly describes the contraints for rate/channels. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project http://www.alsa-project.org SuSE Linux http://www.suse.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
* hdsp channel/sample rate issues 2002-07-20 19:20 ` (no subject) Fernando Pablo Lopez-Lezcano 2002-07-20 23:04 ` Abramo Bagnara 2002-07-21 8:28 ` your mail Jaroslav Kysela @ 2002-07-21 18:56 ` Gary Scavone 2 siblings, 0 replies; 8+ messages in thread From: Gary Scavone @ 2002-07-21 18:56 UTC (permalink / raw) To: Jaroslav Kysela, Takashi Iwai, Paul Davis Cc: alsa-devel, Fernando Pablo Lopez-Lezcano >From earlier replies of Jaroslav and Abramo, it sounds like the API might already be able to handle this and perhaps the problem is in the driver, but I'll just clarify my experience with the hdsp driver. Here is the order of parameter setting I used to follow (on pcm device, not plug interface!): - query supported data formats, then set format. - query the min/max channels, then set channels - query supported sample rates, then set sample rate - query number of periods, then set number of periods - query min period size, then set period size The hdsp driver always reports 18 channels for output (10 for input). If I use the above sequence (setting 18 output channels), the call to set the sample rate fails (ex. 44100 Hz). If I re-order the sequence so that I set the sample rate first, it works. If I attempt to use the 88100 and 96000 rates reported by the driver, the call to set the sample rate fails (Paul says that those rates are not available through the pcm interface at the moment). Paul also says that the maximum number of output channels at these higher rates is less (10 or 8, don't remember). So, the idea is that if I set the sample rate to 96000, the get_channels_min() function should report this lower value. I think there are two issues here. First, the available parameter settings should automatically "scale" based on the previous settings chosen and not require a certain sequence of events to succeed. Second, there needs to be a means for reporting inter-parameter dependencies. --gary On Sat, 20 Jul 2002, Fernando Pablo Lopez-Lezcano wrote: >>> > > on a related note, although the above suggestion will fix this >>> > > particular problem, it seems that it might be wise to consider adding >>> > > a parameter order information field to the driver API, so that drivers >>> > > can say "you have to set param P first, then param N, then param >>> > > O". the default would obviously be "don't care", but for devices that >>> > > lose certain capabilities when certain parameters are set, it would >>> > > make things very much easier. >>> > >>> > agreed that it's good to have such one. >>> > but how to implement this? >>> > from the design of hw_constraint, i don't think it's so easy... >>> >>> I think that this implementation will create a big mess for the >>> application developers. Also, I'm not sure, if it's really needed, because >>> our refining code should already reduce the available configurations. >>> Applications should use *_near() functions in order of their priority. You >>> can't predict, if rate or count of channels or any other parameter is more >>> important for a specific application. >> >>[not exactly an answer but more details on what is actually happening] >> >>I think this is what is happening with the current driver (Gary, please >>correct me if I'm wrong): The application looks at the configuration >>space and selects from it one particular sampling rate. Then it looks at >>the channel count and sees a range of channel counts (10:18 - or some >>numbers like that, I don't remember). The application chooses the minimum >>channel count and the set function fails. >> >>IMHO at that point the configuration space should have changed the number >>of channels available to match the sampling rate selected so that the >>channel count as advertised is legal (ie: if the selected sampling rate is >>one of the "single speed" rates then the range of channels should be >>18:18, if the sampling rate is one of the "double speed" rates then the >>range should be 10:10). >> >>The reverse is also true, if the application first selects number of >>channels the sampling rates should be constrained to the set of rates that >>can be supported by that number of channels. >> >>If it is not possible to do this with the current api, then the next best >>solution I can imagine is to have a switch that changes the mode of the >>card between single and double speed (that would make the dependency >>between sample rate and number of channels dissapear). >> >>-- Fernando ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-07-21 18:57 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-07-18 18:58 double speed (ADAT), and hw params ordering Paul Davis 2002-07-19 10:40 ` Takashi Iwai 2002-07-20 6:54 ` Jaroslav Kysela 2002-07-20 6:57 ` Jaroslav Kysela 2002-07-20 19:20 ` (no subject) Fernando Pablo Lopez-Lezcano 2002-07-20 23:04 ` Abramo Bagnara 2002-07-21 8:28 ` your mail Jaroslav Kysela 2002-07-21 18:56 ` hdsp channel/sample rate issues Gary Scavone
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.