Re: [Alsa-devel] Re: ice1712 driver broken in 2.6.1-mm kernels
Jaroslav Kysela wrote: Can you try 2.6.1-rc1 with alsa-bk-2004-01-20.patch.gz available at our ftp site (/pub/kernel-patches)? It should fix your problem. Thanks a lot Jaroslav! That fixed the problem for me. One small hint for everyone else trying this: Don't forget to readjust your mixer settings, the previously saved settings seem to get lost with the new driver! Is there any reason why the patch is against 2.6.1-rc1? I was quite satisfied with 2.6.1 and don't really want to go back to its first rc. Should I just try to apply the patch to 2.6.1 or 2.6.1-mmX? Will it work for sure, probably or definetly not? Or could you perhaps post your changes as a patch against alsa-driver 1.0.1, so that I can merge alsa into the kernel-sources by myself? gruss, Steffen --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: ice1712 driver broken in 2.6.1-mm kernels
Takashi Iwai wrote: At Wed, 21 Jan 2004 16:08:51 +0100, Steffen Sauder wrote: Is there any reason why the patch is against 2.6.1-rc1? I was quite satisfied with 2.6.1 and don't really want to go back to its first rc. Should I just try to apply the patch to 2.6.1 or 2.6.1-mmX? Will it work for sure, probably or definetly not? i guess it's a typo of 2.6.2-rc1? oh, silly me thought that pros never do typos :o) works fine with 2.6.2-rc1 as well, I'm so glad... Steffen --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: ice1712 driver broken in 2.6.1-mm kernels
Torrey Hoffman wrote: In 2.6.1-mm5, which I'm running at the moment, I just get no sound output. No error messages. The envy24control level meters don't show any sound output. I have the same problem with my Terratec DMX6fire, running gentoo / 2.6.1 with the alsa-kernel directory from alsa-driver-1.0.1 merged into the kernel sources as described in the wiki. Sometimes I hear some kind of looped noise instead of silence which stays the same no matter what I try to play. I found out that unloading all alsa modules, recompiling alsa-lib and restarting alsa seemes to make it work again until the next reboot. I'm very motivated to get this working, and am happy to apply patches, recompile my kernel, or do anything else that would help debug the problem. Same here, I could try out some stuff or send you more information, but I don't know where to start. gruss, Steffen --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] 1.0.0pre1 / ice1712 / mplayer-oss-delay
Takashi Iwai wrote: - PCM OSS emulation was fixed, e.g. mplayer delay problem should be fixed now. Hopefully this doesn't introduce another bug... Strange, the new version doesn't seem to behave any different than the last cvs version I tested (Nov-02) (is there maybe any reason why make install wouldn't properly update everything?). Skipping in mplayer or xmms sill takes half a second, mpg123 needs 30 seconds for starting playback as well as java-apps do. I still have a DMX6fire and am running gentoo with kernel 2.4.20-gentoo-r5. If you need debugging infos please ask, I'm still not sure if the strace-info I sent you once was useful or not. - some bugs in OSS-emulation library are fixed. please test! Are any of those bugfixes related to the problems mentioned above? If not I don't really know where to start testing... - dmix problems with xmms ALSA plugin is solved. I think I can confirm that, I noticed some problems with sample rate conversion before that seem to be gone. Again thanks a lot for your effort on these issues, Steffen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] DMX6fire / ice1712: Long initialization time for playback with Java
Takashi Iwai wrote:
Hi,
does it access via OSS API?
yes I have to use the oss-emulation device, because the alsa devices to
show up in java but can't be used at all. Though they appear as
DMX6Fire [plughw:0,0] they dont seem to be using the plug layer
properly. When asked for what format they support, they say signed pcm,
32-bit mono, little-endian but they can't be used even for streams in
that specific format. All formats I try to play with them just throw an
java.lang.IllegalArgumentException: Line unsupported.
I found out that mpg123 has exactly the same problem with the
oss-emulation, beginning from alsa-driver-0.9.3b, it takes 30 seconds
for playback to start. both mplayer and xmms don't show this problem
with oss output, they only need about 1/2 second for skipping in the
stream as I told before.
strangely 'alsaplayer -o oss' works fine, as does 'aoss mpg123' (using
dmixed output)
could you try stace to check what gets into sleep?
in case you meant strace, I have attached the output of 'strace -r
mpg123 some.mp3' for both alsa-driver 0.9.3a and b. Never used strace
before, so if the information you need is not in the files, please tell
me exactly how to invoke it.
gruss,
Steffen
0.00 execve(/usr/bin/mpg123, [mpg123, Abstrakt.mp3], [/* 51 vars */]) = 0
0.000303 uname({sys=Linux, node=braunschweig, ...}) = 0
0.000154 brk(0)= 0x8093ba8
0.61 open(/etc/ld.so.preload, O_RDONLY) = -1 ENOENT (No such file or
directory)
0.90 open(/etc/ld.so.cache, O_RDONLY) = 3
0.47 fstat64(3, {st_mode=S_IFREG|0644, st_size=63041, ...}) = 0
0.79 mmap2(NULL, 63041, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
0.46 close(3) = 0
0.58 open(/lib/libm.so.6, O_RDONLY) = 3
0.47 read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2405\0...,
1024) = 1024
0.74 fstat64(3, {st_mode=S_IFREG|0755, st_size=186329, ...}) = 0
0.57 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40024000
0.47 mmap2(NULL, 136416, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40025000
0.40 mprotect(0x40046000, 1248, PROT_NONE) = 0
0.41 mmap2(0x40046000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x20) = 0x40046000
0.56 close(3) = 0
0.54 open(/lib/libc.so.6, O_RDONLY) = 3
0.45 read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`X\1\000...,
1024) = 1024
0.58 fstat64(3, {st_mode=S_IFREG|0755, st_size=1449773, ...}) = 0
0.57 mmap2(NULL, 1215204, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40047000
0.40 mprotect(0x4016a000, 23268, PROT_NONE) = 0
0.38 mmap2(0x4016a000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x122) = 0x4016a000
0.60 mmap2(0x4016e000, 6884, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4016e000
0.41 close(3) = 0
0.000354 munmap(0x40014000, 63041) = 0
0.000113 write(2, High Performance MPEG 1.0/2.0/2, 69) = 69
0.000469 write(2, Version 0.59r (1999/Jun/15). Wri..., 69) = 69
0.000191 write(2, Uses code from various people. S..., 54) = 54
0.000162 write(2, THIS SOFTWARE COMES WITH ABSOLUT..., 71) = 71
0.000185 open(/dev/dsp, O_WRONLY) = 3
0.068083 ioctl(3, SNDCTL_DSP_GETBLKSIZE, 0x80732c0) = 0
0.005557 ioctl(3, SNDCTL_DSP_RESET, 0) = 0
0.55 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000403 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.31 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.76 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000156 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.30 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.29 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000148 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.30 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.29 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000145 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.30 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.29 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000145 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.30 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.29 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000146 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000148 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.30 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.000149 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000148 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.31 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.29 ioctl(3, SNDCTL_DSP_SETFMT, 0xb364) = 0
0.000146 ioctl(3, SNDCTL_DSP_STEREO, 0xb364) = 0
0.29 ioctl(3, SOUND_PCM_READ_RATE, 0xb388) = 0
0.29 ioctl(3, SNDCTL_DSP_SETFMT,
[Alsa-devel] DMX6fire / ice1712: Long initialization time for playback with Java
Hello,
I am working on an audio-application with java 1.4, and I noticed that
with the current alsa-release the time neccessary to initialize my
Terratec DMX6fire card for playback (in oss emulation mode) increased a
lot since older versions.
I wrote a small program to measure the time it takes for simply starting
the playback of a wav/aiff file. I noticed that the 0.9.8 release uses a
_lot_ more time on the AudioSystem.getMixerInfo() call (which searches
for all available devices) than older versions. I also noticed that the
times differ a lot for different JDKs, so here are the results for the
sun-jdk-1.4.2.01, blackdown-jdk-1.4.1 and ibm-jdk-1.4.1 with the
different alsa-driver versions.
alsa-driver 0.9.2 - 0.9.3a:
sun: 3.2- 3.3 sec bdn: 1.9- 2.0 sec ibm: 0.7- 0.8 sec
alsa-driver 0.9.3b - 0.9.7:
sun: 6.2- 6.3 sec bdn: 13.7-13.8 sec ibm: 3.7- 3.9 sec
alsa-driver 0.9.8:
sun: 48.0-48.5 sec bdn: 24.7-24.8 sec ibm: 13.7-13.8 sec
alsa-driver cvs-nov-02:
sun: 20.7-20.9 sec bdn: 24.8-24.9 sec ibm: 13.8-13.9 sec
So things got worse between 0.9.3a and .b (the same moment the
mplayer-oss-emulation-delay problem occured!) and 0.9.7 and 0.9.8.
Current CVS version is working a bit better for sun's jdk, but not for
the others. I did not try different alsa-lib versions (used 0.9.2 all
the time) - don't know if this would make any difference.
I attached the source code of the small programm, its syntax is:
java AudioTest AUDIOFILE [DEVICE_NO]
where DEVICE_NO is the index of the java-mixer-device to be used (they
get listed if you start it without the second parameter)
Gruss,
Steffen
import javax.sound.sampled.*;
/**
*
* @author fali
*/
public class AudioTest {
/** Creates a new instance of AudioTest */
public AudioTest() {
}
private static void playAudioFile(String fileName, int device) throws
UnsupportedAudioFileException, LineUnavailableException, java.io.IOException {
long beginTime = System.currentTimeMillis();
System.out.println(checking for available devices on this system...);
Mixer.Info[] mixerInfos = AudioSystem.getMixerInfo();
for (int i=0; imixerInfos.length; i++) {
System.out.println(i+
+mixerInfos[i].getName()+\t+mixerInfos[i].getVendor());
}
System.out.println();
System.out.println(getting mixer device +mixerInfos[device].getName()+...);
Mixer mixer = AudioSystem.getMixer(mixerInfos[device]);
System.out.println(got mixer device, trying to open it...);
mixer.open();
System.out.println(mixer device opened, checking supported lines...);
Line.Info[] supportedLines = mixer.getSourceLineInfo();
for (int i=0; isupportedLines.length; i++) {
System.out.println(supportedLines[i].toString());
}
System.out.println();
java.io.File file = new java.io.File(fileName);
AudioInputStream audioInputStream = AudioSystem.getAudioInputStream(file);
AudioFormat audioFormat = audioInputStream.getFormat();
System.out.println(audio file opened, format is +audioFormat.toString());
Line.Info lineInfo = new DataLine.Info(SourceDataLine.class, audioFormat);
System.out.println(obtaining SourceDataLine for that AudioFormat...);
SourceDataLine sourceDataLine = (SourceDataLine)mixer.getLine(lineInfo);
System.out.println(opening SourceDataLine...);
sourceDataLine.open(audioFormat);
System.out.println(starting SourceDataLine...);
sourceDataLine.start();
long endTime = System.currentTimeMillis();
float seconds = (endTime-beginTime)/1000.0f;
System.out.println(it took +seconds+ seconds to start playback.);
byte[] buf = new byte[1024];
int bytesRead = 0;
while(bytesRead=0) {
bytesRead = audioInputStream.read(buf);
if (bytesRead0) {
sourceDataLine.write(buf, 0, bytesRead);
}
}
sourceDataLine.stop();
sourceDataLine.close();
audioInputStream.close();
}
public static void main(String[] args) {
try {
if (args.length==0) {
System.err.println(first argument has to be an audio file.);
System.exit(-1);
}
String fileName = args[0];
int device = 0;
if (args.length==2) {
device = Integer.parseInt(args[1]);
}
playAudioFile(fileName, device);
} catch (Exception e) {
e.printStackTrace();
}
}
}
Re: [Alsa-devel] DMX6fire / ice1712: Long initialization time for playback with Java
Jan Depner wrote: Just curious, but have you tried making sure that artsd is dead prior to starting? I only get these types of delays if I forget to kill it first (an OS beep will start it). I have disabled the start aRts soundserver on KDE startup option, and there is no artsd process running, so I think that arts can't be the cause. Did you run my sample program or are you speaking of our experience with JavaSound in general? Steffen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [patch] Envy24control access to 6Fire controls
Hi Daniel, This patch against the stable version of envy24control gives access to most of the Terratec DMX 6Fire mixer controls. It also changes the lables on the inputs in the monitor mixer to be more useful. It should have no effect on your envy24control if you are using a card other than the 6Fire. Works fine for me, nice to finally have the input switches available in envy24control. Though envy24control really is flexible, I always wished to have an less complex mixer for the DMX6Fire, but never took the time to write one or patch e24c for that purpuse. So if you ever get in that mood again, it would be nice if you could also change the other labels in the patchbay/router tab and the analog volume tab. (ADC0-In CD L , ADC1-In CD R, ..., IGPA 0 - Gain CD-L, IPGA 1 - Gain CD-R ...). And I really wish I had a mixer that would handle the stereo channels as what they are. Its annoying to have 6 sliders for adjusting the volume of your line-in, for example, but since you're no programmer, you probably won't fix that :) Note that I'm not a programmer, so there might be huge errors in this... Haven't really looked at the code, but it seems to work flawlessly. gruß, Steffen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] OSS emulation delays (?)
ok, finally i can reproduce this bug, too. this happens when the plug layer is used, e.g. sample-rate or format conversion is needed. that's why this doesn't appear on most machines. the attached patch should fix the problem. It did so indeed, thanks a lot. (but of course, it has nothing to do with the oss-emulation problem... please let me know if you find the exact alsa version getting broken.) 0.9.3a works fine, but all versions 0.9.3b and later all seem to have that problem. gruss, Steffen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] OSS emulation delays (?)
I've had similar problems with mplayer and my Terratec DMX 6fire (also ice1712) MPlayer isn't quite so slow, but there is a decent pause while seeking in movies. I've had this problem with mplayer and oss emulation since alsa 0.9.3 i think (not quite sure). In older versions it worked fine, but in newer versions and the current cvs it takes about a second for mplayer to skip anywhere. I didn't have this problem with any other app than mplayer though. With the xmms ALSA driver, this is not a problem. Unfortunately mplayer and ALSA don't seem to get along with my card (ice1712... maudio delta-44), but with audio disabled seek times are fine. Same problem here again, mplayer's alsa-output has been broken for me since I have that card (1.5 years). Audio seems to be running fine, but video plays at about one fps, and after few seconds the buggy-audio-driver message pops up. Because mplayer is the only app having problem with the alsa-driver, I always thought it was mplayer's bug, but I didn't dare to post on their mailinglists :o). I ended up using arts, because it works perfectly with the ice1712 drivers and both xmms and mplayer. gruss Steffen --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
