File: README.xingmp3enc

package info (click to toggle)
liveice 1.0-1.1
  • links: PTS
  • area: contrib
  • in suites: woody
  • size: 516 kB
  • ctags: 607
  • sloc: ansic: 6,147; tcl: 369; sh: 174; makefile: 94
file content (140 lines) | stat: -rw-r--r-- 5,226 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
Some notes on the Xing mp3 encoder.

The Xing Mp3 encoder for linux is by far the fastest encoder available, and 
produces good quality MPEG1 and MPEG2 streams.

When the beta version was released I quickly hacked liveice to work correctly 
with it - at least it worked well in mono mode, stereo was broken and didn't 
work. When the production verions appeared something had changed which managed
to stop it working completely with liveice.

Basically xing has problems reading from pipes - this is annoying if you want
to record audio live and encode it since they've managed to make this a
difficult task.

There are 2 solutions which are possible.

Solution 1
==========

The first allows mono encoding without any modification to LiveIce, and a 
simple modification to the Linux kernel.

(1) Go to you kernel source directory, and edit fs/pipe.c
(2) find the line 
static long long pipe_lseek(struct file * file, long long offset, int orig)
  {
  return -ESPIPE;
  }

This basically returns an error if somethign tries to seek on the pipe.

(3) comment this out and replace it with

static long long pipe_lseek(struct file * file, long long offset, int orig)
{
        if(orig==2)
                return 2147483647;
        if(offset>=0)
                return offset;
        else
                return -offset;
}

this returns some numbers which make pipes look like very long files when 
programmes try to seek in them. Xing seeks to teh end of the file to find
out how long the file is and allocates a buffer based on this, if it gets an
error it somehow decides it doesn't need an output buffer.... so this makes
the pipe look like a 2GB file. Xing doesn't do any thign strange after it
passes 2GB of data so there's no real limit - I would try larger numebrs
except I suspect that the xing code would have problems.

(4) recompile and reinstall the kernel....

Now this changes the behaviour of all pipes... but I haven't found anything 
which has a problem with this. and the code is probably more stable and
secure than my seconds - more complicated option.


Solution 2
==========

The second option works for stereo modes as well but requires you to load
a kernel module which I've written and, judging by the number of problems
that people have with my liveice code this could be a dangerous prospect. 
I think you'd have to be mad to let my code contaminate your kernel ;-)

Basically these instructions are guidelines and I can't gurantee that this 
won't trach your system, but then again I can't think of any way that might 
happen. So, no guranatees, but don't let that stop you.

It installs a device handler for a new type of device which is similar to a 
pipe but with a larger buffer and capable of handling large reads. In 
Stereo mode the xing encoder asks for 27Kbytes in each read (strange number,
don't ask me why) and decides that it's reached the end of the file when it 
gets given any less. This is needless to say very annoying when a normal
pipe will only handle reads and writes of 4096 bytes. So this special
pipe can handle those big reads and writes, and as a bonus buffers more data 
in the hope of reducing the number of calls to the scheduler and improving
overall performance.

(1) compile livepipe.c

$ gcc -DMODULE -D__KERNEL__ -DLINUX -O -c livepipe.c

(2) modify liveice to be less paranoid about its pipes
edit liveice.h and comment out

#define PARANOID_PIPES

and recompile liveice - this just stops it quitting when it finds a device
where it expects a pipe.

(3) now load the module and check the kernel messages to see what device 
number it's been allocated - you need to be root to do this.

# insmod livepipe
# dmesg | tail
Jul 11 17:36:15 arpc65 kernel: I suggest you use: 
Jul 11 17:36:15 arpc65 kernel: mknod <name> c 254 <minor> 
Jul 11 17:36:15 arpc65 kernel: minor number 0-15 are valid for this device 
Jul 11 17:37:00 arpc65 kernel: Removing module from kernel 
Jul 11 17:37:12 arpc65 kernel: Registration is a success. The major device numbe
r is 254. 
Jul 11 17:37:12 arpc65 kernel: If you want to talk to the device driver, 
Jul 11 17:37:12 arpc65 kernel: you'll have to create a device file.  
Jul 11 17:37:12 arpc65 kernel: I suggest you use: 
Jul 11 17:37:12 arpc65 kernel: mknod <name> c 254 <minor> 
Jul 11 17:37:12 arpc65 kernel: minor number 0-15 are valid for this device 

(4) now in the directory you normally run liveice from there will be a 
directory called .liveice_temp_files full of files called mpeg.pipeX and 
raw.pipeX

you want to replace some of the raw.pipeX files with livepipe devices - 

# cd .liveice_temp_files
# ls -l
total 0
prw-------   1 spm      spm             0 Jul 12 13:30 mpeg.pipe0
prw-------   1 spm      spm             0 Jun 27 16:42 mpeg.pipe1
prw-------   1 spm      spm             0 Jul 12 13:30 raw.pipe0
prw-------   1 spm      spm             0 Jun 27 16:42 raw.pipe1
# rm raw.pipe0
# mknod raw.pipe0 c 254 0


You only need to replace the pipes which are going to be used by stereo 
channels.

(5) setup liveice.cfg and run it

(6) Rejoice as you broacast 128Kbit stereo!

I'd like to incorporate the  pipe device creation into liveice but I'm
a bit dubious for the moment...

Copyright 1999 Scott Manley